Bądź na bieżąco - RSS

Jak naprawić URL po przeniesieniu witryny WordPress pod nowy adres

Grudzień 7th, 2013 | Brak Komentarzy | Kategoria: Bez kategorii, Linux, Porady, Windows

WordPressWordPress jest jednym z najbardziej popularnych systemów zarządzania treścią tzw. CMS. Sam używam wyłącznie WordPressa i wysoko go sobie cenie. Nie chciałbym rozpisywać się o zaletach tego oprogramowania, jak również tworzyć kolejnego poradnika instalacji czy konfiguracji. Materiałów w sieci jest wystarczająco dużo. Tym razem chciałbym pokazać jak rozwiązać bardzo konkretny problem, związany z przenoszeniem, tworzeniem kopii testowych itp. witryn utworzonych za pomocą opisywanego CMSa.

Generalnie, wykonywanie kopii witryn WordPressa to przede wszystkim:

  • kopiowanie i przenoszenie bazy danych oraz
  • kopiowanie i przenoszenie całej struktury katalogów i plików

Niemniej, nawet jeżeli całkiem nieźle radzimy sobie z powyższymi zadaniami to trzeba pamiętać, że nasza strona WordPress jest widoczna jako adres URL w sieci np. ‚www.strona-wp.pl’. Tworząc jej kopie albo przenosząc pod nowy adres trzeba pamiętać o uaktualnieniu bazy danych. WordPress zapisuje bowiem wyświetlane elementy typu grafiki, dokumenty itp. za pomocą ich adresu URL. Często, przeniesiona strona, właśnie z tego powodu nie chce wyswietlać żadnych grafik bądź innych obiektów. Co możemy zrobić? Wykonać trzy polecenia UPDATE w środowisku bazy danych:

  1. UPDATE wp_options SET option_value = replace(option_value, →
    'http://www.stary-adres.pl', 'http://www.nowy-adres.pl') →
    WHERE option_name = 'home' OR option_name = 'siteurl';
  2. UPDATE wp_posts SET guid = replace(guid, →
    'http://www.stary-adres.pl','http://www.nowy-adres.pl');
  3. UPDATE wp_posts SET post_content = replace(post_content, →
    'http://www.stary-adres.pl', 'http://www.nowy-adres.pl');

Reszte poprawek musimy wykonać ręcznie, edytując konfiguracje witryny. Niemniej przytoczone polecenia pozwolą na pewno zaoszczędzić mnóstwo czasu.

MG

Tagi: , , ,

Serwer NTP w systemie Windows Server 2008 R2

Październik 5th, 2013 | Brak Komentarzy | Kategoria: Bez kategorii, Porady, Windows

NTPProblem synchronizacji czasu w sieci lokalnej bywa często pomijany. W sieciach z jednorodnym środowiskiem np. Linux czy Windows nie stanowi dużego wyzwania. Jednak co zrobić gdy mamy ekosystem (popularny ostatnio termin) mieszany. Stacje robocze Windows są od razu wyposażone w klienta synchronizacji czasu. Nie chce on jednak współpracować z bardzo dobrym oprogramowaniem, serwerem NTP, na Linuxie. Chyba jeszcze nikomu nie udało się zmusić do poprawnej współpracy wspomnianych systemów. Nie pozostaje zatem nic innego jak przygotwać serwer NTP w środowisku Windows. Nasz bohater, Windows Serwer 2008 R2 posiada taką usługę, jednak myli się ten, kto myśli, że jego konfiguracja polega wyłącznie na tzw. ‚wyklikaniu’.

Z drugiej strony wystarczy, że spełnimy 3 warunki:

  1. Utworzymy regułę zapory systemowej dla ruchu przychodzącego, dla portu 123 i protokołu UDP
  2. Upewnimy się, że usługa ‚Czas systemu Windows’ jest skonfigurowana jako uruchomienie automatyczne
  3. Znamy pewne ‚magiczne’ polecenie…

W zasadzie wszystko sprowadza się do punktu 3 a komenda wygląda tak:

w32tm /config /syncfromflags:manual →
/manualpeerlist:europe.pool.ntp.org → 
/reliable:yes /update

Cały proces kończymy poleceniem:

w32tm /resync

Od tego momentu możemy konfigurować stacje robocze wskazując powyższy serwer jako źródło czasu.

Na koniec wypada dodać, że w Internecie można znaleźć dużo materiałów, oficjalnych bądź nie, na ten temat. Jednak przytoczona tutaj metoda jest sprawdzona i skuteczna.

MG

Tagi: , ,

Rola rekordu SRV w konfiguracji MS Exchange

Lipiec 7th, 2012 | Brak Komentarzy | Kategoria: Bez kategorii, Porady, Windows

Microsoft Exchange Server jest obecnie jednym z popularnych serwerów pracy grupowej w firmach. Nie jest to rozwiązanie tanie. Szczególnie jeśli uwzględnimy koszt budowy infrastruktury zgodnie z zaleceniami Microsfotu, koszt licencji dostępowych CAL itd. Tak czy inaczej jeżeli zdecydowaliśmy się już na zakup oprogramowania i nie mamy kilku serwerów do wykorzystania musimy liczyć się z koniecznością gruntownego zabezpieczenia naszego głównego serwera Exchange. Konfiguracja, o której mówie zakłada zainstalowanie 3 głównych ról serwera (Hub Transport Server, Mailbox Server oraz CAS – Client Access Server) na jednym serwerze. W omawianym przypadku nie zajmujemy się serwerem brzegowym (Edge Transport Server).

Ponieważ na wspomnianym serwerze instalujemy usługi dostępowe CAS (w tym dla klientów mobilnych, z poza sieci firmowej) należy zabezpieczyć go wszelkimi możliwymi środkami. Najprostszym i najtańszym rozwiązaniem jest zorganizowanie komunikacji z wykorzystaniem protokołu HTTPS (port 443). Klient poczty Microsoft Outlook posiada możliwość połączenia się z serwerem Exchange za pomocą tandemu RTP over HTTPS. Można zatem łatwo dodać regułę na firewallu firmowym, umożliwiącą komunikację z zewnątrz z serwerem Exchange na porcie 443.

Niestety Outlook wykorzystuje często funkcje autokonfiguracji działającą w oparciu o usługę Autodiscover. W tym miejscu dochodzimy do sedna problemu opisywanego w tym artykule. Jeżeli domena Active Directory (np. corp.firma.com) różni się od domeny internetowej (np. firma.com) to Outlook będzie zasypywał nas komunikatami o błędach. Istnieje wiele sposobów zapobiegania takim sytuacjom. Jednym z najbardziej skutecznych jest wykorzystanie rekordu SVR na zewnętrznych serwerach nazw. W ten sposób Outlook z każdego miejsca w internecie będzie mógł połączyć się z naszym serwerem Exchange. Rekord SRV dla Exchange będzie miał następującą postać (użyłem przykładu dla popularnego serwera bind):

_autodiscover._tcp.firma.com. IN SRV 0 5 443 server.corp.firma.com.

Musimy jeszcze pamiętać o rekordzie A dla domeny z przykładu – firma.com:

server.corp IN A 1.2.3.4

Takie rozwiązanie pozwoli uniknąć w przyszłości chóru narzekających użytkowników. I o to w zasadzie w tym wszystkim chodzi…

MG

Tagi: , , ,

Jednorazowe korzystanie z Proxy podczas aktualizacji

Czerwiec 2nd, 2012 | Brak Komentarzy | Kategoria: Bez kategorii, Linux, Porady

Jednym z wielu zadań należących do administratora systemu Linux Debian jest wykonywanie aktualizacji. Funkcjonuje nawet anegdota, że użytkownika Debiana można rozpoznać po tym, iż każdy dzień rozpoczyna od komendy:

apt-get update

Tak czy inaczej czasami zdarza się, że aktualizacje ciągną się w nieskończoność a szybkość połączenia pozostawia wiele do życzenia. Nie są to niestety sporadyczne przypadki. Dodatkowo jeżeli mamy do czynienia z kilkoma serwerami w sieci, które powinniśmy zaktualizować sytuacja może być irytująca. Rozwiązaniem w tym przypadku jest serwer proxy. Co zrobić jednak, gdy chcemy z niego skorzystać tylko jednorazowo na czas aktualizacji? Rozwiązanie jest bardzo proste i wymaga jedynie dostępu do konsoli. Wydajemy polecenie:

http_proxy='http://adres_serwera_proxy:port'

co pozwoli nam na wykorzystanie proxy ad-hoc bez rekonfiguracji ustawień systemowych.

MG

 

Tagi: , ,

Termometr IP dla ochrony serwerowni – część II

Maj 5th, 2012 | Brak Komentarzy | Kategoria: Bez kategorii, Porady, Windows

Jakiś czas temu opisywałem rozwiązanie polegające na zdalnym pomiarze parametrów pracy pomieszczenia (np. serwerowni). Przez ten czas zmieniła się konfiguracja obserwowanej serwerowni i pojawiły się nowe urządzenia. Pomyślałem zatem o scentralizowanym rozwiązaniu, które umożliwi obserwacje stanu większej ilości czujników a przy tym pozwoli na generację alarmów w sytuacjach krytycznych. Konfigurowanie pojedynczo każdego nowego czujnika IP jest pracochłonne i nie daje możliwości budowania złożonych akcji (alarmów), które polegają na analizie stanu kilku czujników.

Producent termometru IP udostępnił na swojej stronie darmową wersję aplikacji Wix, która umożliwia m.in.

  • obserwację pomiarów z kilku urządzeń
  • wykreślanie historii pomiarów
  • budowanie akcji z prostą logiką warunków
  • wysyłanie wiadomości alarmowych via e-mail, SMS

W tej wersji aplikacja Wix nie jest być może szczególnie zaawansowana ale oferowała funkcjonalność, której poszukiwałem. Jeśli ktoś poszukuje lekkiego i prostego w konfiguracji rozwiązania można ją śmiało polecić. Dla bardziej wymagających pozostaje zabawa z oprogramowaniem urządzeń firmy Papouch za pomocą API udostępnionego na stronie producenta.

MG

Tagi: ,

Jak dodać obsługę SVN do XAMPPa

Kwiecień 7th, 2012 | Brak Komentarzy | Kategoria: Bez kategorii, Linux, Porady

XAMPP jest bardzo wygodnym zestawem typu Apache+PHP+MySQL. Moim zdaniem jego przewaga nad podobnymi rozwiązaniami wynika z dopracowanego projektu oraz możliwości instalacji przez rozpakowanie archiwum do katalogu ‚/opt’. Wykonywanie kopii zapasowych oraz przenoszenie całego serwisu z serwera na serwer jest również bardzo proste, wystarczy bowiem zatrzymać usługę, zrobić kopię (np. za pomocą tar) i przenieść na inny komputer.

XAMPP nie jest jednak pozbawiony drobnych wad. Jedną z nich jest brak wbudowanej obsługi systemu kontroli wersji SVN. Taka właściwość jest bardzo przydatna jeśli chcemy utworzyć np. repozytorium dokumentów za pomocą WebDAV (odpowiedni moduł jest standardowo wbudowany w XAMPP).

Instalację SVN zaczynamy od instalacji odpowiednich pakietów z repozytorium:

apt-get install subversion libapache2-svn

Następnie przygotowywujemy katalog dla repozytorium SVN np. ‚/var/svn’:

mkdir /var/svn/

Zakładamy pzrykładowy projekt o nazwie test:

svnadmin create --fs-type fsfs /var/svn/test

Potem dodajemy użytkownika (np. marcin) z uprawnieniami do naszego projektu. Dwa pierwsze wiersze kodu poniżej wykonujemy jednorazowo:

rm -f /var/svn/test/conf/passwd
touch /var/svn/test/conf/passwd
htpasswd /var/svn/test/conf/passwd marcin

Tworzymy grupę subversion i ustawiamy uprawnienia dla katalogu ‚/svn’:

groupadd subversion
chmod -R 777 /var/svn/*

Żeby XAMPP mógł obsłużyć SVN konieczne są dwie biblioteki mod_authz_svn.so oraz mod_dav_svn.so. Możemy je np. skopiować z katalogu Apache, pod warunkiem, że zainstalowaliśmy wcześniej pakiet apache2:

cp /usr/lib/apache2/modules/mod_authz_svn.so /opt/lampp/modules/
cp /usr/lib/apache2/modules/mod_dav_svn.so /opt/lampp/modules/

Teraz możemy wyedytować plik ‚/opt/lampp/etc/httpd.conf”, żeby najpierw pod linią zawierającą wpis LoadModule ssl_module modules/mod_ssl.so umieścić fragment:

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

a następnie na końcu pliku dodać:

# Subversion repositories

<Location /test>
DAV svn
SVNPath /var/svn/test
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /var/svn/test/conf/passwd
Require valid-user
SSLRequireSSL
</Location>

Po zatrzymaniu i ponownym uruchomieniu XAMPPa, możemy rozpocząć testowanie opisanego rozwiązania.

MG

Tagi: , ,