Autor: Marcin Pietrzak Strona 26 z 41

http i https oraz upierdliwość firefoxa

Firefox ma fajną historię. Bardzo fajną i podpowiadającą, co pewnie nie jest żadnym halo, bo większość przeglądarek pewnie to ma. Innych przeglądarek niż FF używam tylko w końcowych testach tworzenia strony. Ale do rzeczy.

Korzystałem z jednego wiki, które w pewnym momencie zostało przestawione na https, co samo w sobie byłoby bez znaczenia, oprócz tego, że FF pamiętał ten adres i nijak nie chciał zapamiętać nowego. Pewnie dlatego, że i tak odwiedzałem uzupełnioną stronę, na której witał mnie standardowy błąd.

Rozwiązaniem, które podpowiedział mi depesz jest wyczyszczenie pamięci FF, a ponieważ do trzymania historii używa on SQLite’a to procedura jest bardzo prosta.

Po pierwsze należy wyłączyć firefoxa :D.

Potem łączenie:

sqlite3 places.sqlite

Oraz kasowanie upierdliwego wpisu:

DELETE FROM moz_places WHERE url LIKE 'http://adres%';

Pełen opis tabel i nie tylko znajdziesz tutaj:

IP.Board i uszkodzony index

Jest sobie forum postawione na IP.Board, który jest prawie idealny. Prawie, ponieważ używa mysql’a zamiast postgresql’q. Gdyby używał tego ostatniego były perfekcyjny.

Tabela posts używa inno db, o którym im więcej wiem, tym bardziej mam go dość. No ale wracając.

Z cron’a chodzą sobie backupy baz danych, między innymi mysqldump, który od kilku dni (niestety) wywalał się z następującym komunikatem:

mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `ibf_posts` at row: 111598
mysqldump: Got error: 2002: Can't connect to local MySQL server through socket

Co w logach widziane było tak: (zresztą select count(*) from ibf_posts, skutkowało tym samym błędem)

InnoDB: Page checksum 396689542, prior-to-4.0.14-form checksum 4074025863 stored checksum 4054066906, prior-to-4.0.14-form stored checksum 1768235130
Page may be an index page where index id is 0 6702
Database page corruption on disk or a failed file read of page 400.
You may have to recover from a backup.
It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error.
If the corrupt page is an index page you can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption.
See also InnoDB: about forcing recovery.
Ending processing because of a corrupt database page.
Number of processes running now: 0
restarted

Strona polecana przez logi jest ok, poza tym, że procedura tam opisana do niczego nie prowadzi. Mimo:
InnoDB: !!! innodb_force_recovery is set to 4 !!!
Skończyło się propozycją wysłania stack trace’a, zgodnie zkolejną opisaną procedurą: http://dev.mysql.com/doc/mysql/en/using-stack-trace.html

Mam to w nosie.

A ponieważ cała baza i tak działa (aktualnie backupuje się co godzina katalog /var/lib/mysql i jest spokój.)

W sumie trzeba mi było od razu zastosować się do procedury opisanej na pierwszej polecanej stronie. Czyli skopiować dane, wywalić tabelę, założyć tabelę, przywrócić dane.

W sumie wygląda prosto, ale … nie miałem jak wykonać dumpa, co gorzej większość zapytań korzystających z całych kluczy wywalało się. Całe szczęście dało się wyciągnąć z całej tabeli pole pid, które jest kluczem głównym tej tabeli.

Mając to pole, mogłem wyciągnąć dane po kolei i zapisać je sobie na boczku, potem już łatwo: skasować tabelę, załadować (bez kluczy) wgrać dane i zapiąć klucze.

W czasie pracy powstały następujące pliki:

  • read.pl – czyta dane z bazy
  • write.pl – zapisuje do bazy dane z pliku
  • ifb_posts.sql – kasuje
  • ifb_posts_keys.sql

Które można sobie pobrać tutaj: ip.board.posts.tar.bz2

Na koniec warto wykonać:

OPTIMIZE TABLE ibf_posts;

Z ciekawostek w czasie pracy:

Dla niektórych zapytań pojawiał się następujący błąd: ERROR 1030 (HY000): Got error -1 from storage engine co doprowadziło do przeczytania wątku na stronie mysql’a: http://bugs.mysql.com/bug.php?id=30225 który mnie po prostu rozbawił, jako że nie uznano tego błędu za błąd, a receptą była aktualizacja. Słabo?

mod_perl – „zabawne”

Jest sobie klient. Klient dostaje od swojej nadrzędnej jednostki miejsce na serwerze. Do tej pory cool.

Dostałem więc namiary na konto, ftp’a, mysql’a.

Środowisko lokalne ustawione, aplikacja webox wygenerowana, szablon wstukany, więc wgrywam na serwer. Pierwsze pozytywne wrażenie: włączony mod_rewrite oraz allowOverride ustawione na all. Cudnie, bo do niedawna i to trzeba było się kopać.

Potem było już tylko gorzej. Nie ma mod_perla, więc napisałem poprzez system ticketowy prośbę o jego włączenie, a oto otrzymana odpowiedź:

ze względów bezpieczeństwa oraz wydajności serwera nie mamy w ogóle uruchomionego mod_perl. Na razie jest Pan jedyną osobą, która zgłosiła potrzebę użycia Perla, więc nie możemy tego uruchomić, ponieważ pożytek z mod_perl dla Pana będzie mniejszy niż szkoda dla wszystkich pozostałych użytkowników serwera.

Przyznam się, że strach mnie ogrania jak widzę taki poziom niewiedzy u kogoś kto teoretycznie zarządza serwerem.

Ale w myśl zasady o kopaniu, dostałem jeszcze propozycję nie do odrzucenia:

Zgaduję, że nie jest Pan zadowolony z wgranego domyslnie SkyblueCanvas. Polecam Quick.CMS – jest on prostszy od Skyblue i również nie wymaga bazy danych. Jeżeli potrzebuje Pan czegoś o wiekszych możliwościach to polecam Joomlę. Najwięcej możliwości oferuje chyba Drupal, ale zrobienie strony w nim jest bardzo pracochłonne.
Generalnie, może Pan użyć czegokolwiek, co jest napisane w PHP.

Prawda, że miłe? Prosisz o perla, a sugerują ci php’a.

CSS Sprites

Polecam omówienie techniki, którą powinien znać KAŻDY szanujący się webowiec.
Learning CSS Sprites

nginx + ssl

Jakiś czas temu stawiałem wiki, gdzie kolejnym krokiem po tym jak serwis został zablokowany poprzez htaccess było przestawienie całości do pracy z certyfikatem ssl z wykorzystaniem szyfrowania. Konieczność jeżeli mają tam być przechowywane np. hasła rootów.

Certyfikat który podpiąłem jest certyfikatem który sam podpisałem.

generowanie klucza prywatnego

wykonanie następującego polecenia:
openssl genrsa -des3 -out server.key 1024
spowoduje wygenerowanie klucza:
Generating RSA private key, 1024 bit long modulus
.........++++++
..............++++++
e is 65537 (0x10001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:

pierwszą wadą tego klucza jest fakt posiadania przez niego hasła, co by oznaczało, że przy każdym restarcie serwera korzystającego z tego klucza, istniała by potrzeba wpisywania tego hasła.

generowanie CSR

Pierwszym elementem prowadzącym do wygenerowania certyfikatu jest wygenerowanie pliku który dopiero potem będzie podpisany przez wcześniej wygenerowany klucz prywatny.

openssl req -new -key server.key -out server.csr

zostaniemy poproszeni o hasło:

Enter pass phrase for server.key:

By potem wypełnić dane:

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:mazowieckie
Locality Name (eg, city) []:Warszawa
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Firma
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

utworzenie klucza bez hasła

Aby usunąć „wadę” i posiadać klucz bez hasła należy wykonać:
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key

podpisanie CSR’a

Na sam koniec generowania klucza ssl, musimy go podpisać np na rok:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Co daje nam efekt:
Signature ok
subject=/C=PL/ST=mazowieckie/L=Warszawa/O=Firma
Getting Private key

instalacja klucza i certyfikatu

Ponieważ używanym serwerem jest nginx to kopiuję sobie:
cp server.crt /etc/nginx/ssl/cert.pem
cp server.key /etc/nginx/ssl/cert.key
podpinanie do konfiguracji

do konfiguracji dodałem:
listen 443;
ssl on;
ssl_certificate /usr/local/nginx/conf/cert.pem;
ssl_certificate_key /usr/local/nginx/conf/cert.key;

potem restart i śmiga... prawie.

Okazało się że wiki działa dobrze, ale nie grzeje :D. Całość wiki działa dobrze, oprócz niektórych odnośników. Np. "losowa strona" powoduje przejście na port 80. Kluczem jest zmiana konfiguracji w pliku: LocalSettings.php
$wgServer = "https://serwer...";

błąd ustawiania locale

svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LC_ALL is pl_PL.UTF8
svn: warning: please check that your locale name is correct

śladem tego co się dzieje w locale jest sprawdzenie listy dostępnych poprzez:
locale -a
i jak się okazało po prostu pl_PL.utf8 nie istniało w moim systemie, więc trzeba doinstalować:
apt-get install language-support-pl

wiki potrzebna od zaraz

Jak liczba obsługiwanych maszyn zrobi się większa niż jeden (lub dwadzieścia, jak to woli) to warto by było gdzieś zapisać pewne rzeczy związane z działaniem skryptów, konfiguracją usług oraz wielu innych ważnych i mniej ważnych rzeczy. Oczywiście można wszystko trzymać w plikach, a pliki w repozytorium, ale przy osiągnięciu pewnej masy zapisanych informacji zaczynają się trudności w dostępie do zgromadzonej wiedzy, szczególnie, że serwerów i usług raczej przybywa niż ubywa. Wydaje się, że rozwiązaniem jest postawienie wiki. I tak właśnie się stało, choć z przygodami.

Po pierwsze wiki to raczej filozofia budowy strony i trzymania informacji, a nie konkretne rozwiązanie programistyczne, co odkryłem z pewnym zdziwieniem, próbując dobrać taki soft, który spełniałby nasze wymagania. Na początek miało to być perlowe i pracować z postgresem. Korzystając ze strony Wiki Choice Wizard i wyklikując pracowicie poszczególne wymagania w pewnym momencie osiągnąłem grala: na liście pozostał tylko jeden soft o wdzięcznej nazwie mojomojo. Spełniało wszystkie wymagania a dodatkowo najmilsza możliwa licencja: BSD.

Instalacja poszła jak z płatka, problemy zaczęły się po chwili i były związane z założeniami. Na serwerze usługi są rozdzielone pomiędzy chrooty. W tej sprawie interesują nas 2 z nich. Pierwszym chrootem jest chroot zwany głównym webowym, w których działa nginx jako serwer proxujący. Założeniem było również to, że ma proxować urla do serwera działającego w innych chroocie na losowym porcie (bezpieczeństwo), czyli serwis pracujący w domena/wiki znajduje się na innym serwerze. Konfiguracja wygląda następująco:

różnice w CSS dla Internet Explorer 6, 7 i 8

Świetne zestawienie:

CSS Differences in Internet Explorer 6, 7 and 8

Pokazane punkt po punkcie jakie selektory działają w której z wersji przeglądarki.

Ogólna konkluzja jest taka, że wersja 6 była/jest po prostu strasznie fatalna. Bardziej nawet niż myślałem.

Jakie klucze stosować, jakie wybrać

Josh Berkus w cyklu „Primary Keyvil” rozważa kwestie związane z używaniem kluczy głównych w tabelach. Zastanawia się nad kluczami będącymi w jego odczuciu surogatami prawdziwych kluczy głównych. Za taki surogat uważa klucze oparte na automatycznie inkrementowanych polach w bazie (autoincrement dla mysql’a oraz serial dla postgres’a) i przyznam, że podane argumenty są bardzo mocno i ciężko mi z nimi polemizować.

Generalnie autor zachęca do stosowania kluczy głównych które są rzeczywistym wyróżnikiem. Rozważmy sytuację w której mamy trzy proste tabele: users, groups, user2group – dwie pierwsze zawierają dane dotyczące odpowiednio: użytkowników oraz grup, ostatnia zawiera informację do których grup należy użytkownik.

Jeżeli zastosujemy jako klucze główne pola „ID” to w efekcie tabela user2group przyjmie zawartość:

+---------+----------+
| user_id | group_id |
+---------+----------+
|       1 |        1 |
|       2 |        2 |
|       2 |        6 |
+---------+----------+

Co jak widać niewiele mówi.

W przypadku w którym za klucze przyjmiemy odpowiednio email użytkownika oraz nazwę grupy to taka tabela będzie miała następującą zawartość:

+----------+----------+
| email    | group    |
+----------+----------+
| illi@x   | root     |
| gurthg@x | adm      |
| gurthg@x | www-data |
+----------+----------+

Trudno się nie zgodzić, że pomyłka w insercie typu: INSERT INTO tabela VALUES ( 1, 2 );
jest trudniejsza do wychwycenia niż w: INSERT INTO tabela VALUES ( 'illi@x', 'adm' );

Czytanie danych, szczególnie po latach albo obcych jest o niebo łatwiejsze wtedy kiedy naszymi kluczami są dane które coś znaczą.

Następnym drobnym zyskiem jest fakt zmniejszenia ilości zapytań lub joinów w zapytaniach.

Zauważymy, że w ostatnim przypadku żeby wylistować adresy email użytkowników należących do danej grupy, wtedy kiedy znamy tylko jej nazwę, wymusza w pierwszym przypadku użycie dwóch joinów. W drugim przypadku jest to prosty select. Oczywiście sytuacje tak proste raczej nie występują w życiu, ale są dobrym przykładem na zobrazowanie korzyści.

Oczywiście są sytuacje w których będę nadal używał kluczy opartych o inkrementowaną liczbę naturalną, ale tylko tam gdzie uznam to za naprawdę konieczne.

Natomiast w kwestiach prostych zostałem całkowicie przekonany do używania jako klucze główne takich danych, które niosą ze sobą rzeczywistą różnicę między rekordami.

All in One SEO Plugin Options

Ta wtyczka zaczyna mnie najłagodniej mówiąc – strasznie denerwować. Przy każdej aktualizacji wymaga aktywowania. Nudne. Chyba sobie kopię zrobię, która nie będzie się aktualizować.

Strona 26 z 41

Oparte na WordPress & Theme by Anders Norén