W tym roku Pingwinaria, czyli zlot miłośników i sympatyków systemu operacyjnego spod znaku pingwina, odbyły się w Spale w dniach 12-15 maja 2011. Z racji ogromnej sympatii dla owego systemu nie mogło na tej imprezie zabraknąć naszego przedstawiciela.

Udział w imprezie zaczęliśmy od piątkowego poranka, logując się w ośrodku wypoczynkowym Zacisze, w sam raz przed pierwszą sesją dnia, dotyczącą pozawłamaniowych aspektów bezpieczeństwa informatycznego. Bardzo ciekawą prelekcję poprowadził Radosław Korzeniewski, opowiadający o wdrożeniu systemu backupowego Bacula u dużego ISP. Część prelekcji była również poświęcona analizie i wdrożeniu Baculi w grupie &TP. Na koniec sesji Alex przedstawił analizę stanu obecnego, wykorzystania oraz sukcesów i porażek bytności Linuksa. Poobiednia sesja dotyczyła otwartości oprogramowania oraz przetargów publicznych, z którymi nie jest najlepiej w naszym kraju. Wieczór natomiast miło upłynął na imprezie integracyjnej przy ognisku i gitarze oraz napojach różnych

Sobota zaczęła się ciekawą sesją, dotyczącą wdrażania protokołu IPv6 m.in. w Armii Szwajcarskiej. Nawiązując do zbliżającego się World IPv6 day mało który operator sieci globalnej, nie wspominając o naszych dużych operatorach, jest przygotowany na wdrażanie nowego protokołu. Wiele przyczyn leży niestety po stronie sprzętu, zarówno klasy operatorskiej (błędy w oprogramowaniu, brak stabilności działania), jak i urządzeń przeznaczonych do użytku domowego (czy Twój router wifi obsługuje IPv6?). Sesja poobiednia dotyczyła Linuksa na urządzeniach wbudowanych – tak, Linux jest obecny w wielu telefonach komórkowych, lodówkach, dekoderach cyfrowych i wielu, wielu innych urządzeniach przydatnych w życiu codziennym. Wieczorem odbyło się walne zebranie członków PLUG, na którym również jako członkowie grupy byliśmy obecni.

Niedziela przywitała nas deszczową aurą i prelekcją na temat certyfikatów LPI, podczas której wywiązała się ciekawa dyskusja na temat sensu, jakości oraz sposobów certyfikowania. Następnie wyposażeni w puszki po kawie (a jakże), z których zrobiliśmy niskobudżetowe aparaty fotograficzne (camera obscura) ruszyliśmy na bobry, jednak deszcz skutecznie nas zawrócił do ośrodka. Po ostatniej prelekcji ukazującej potęgę wiersza poleceń nadszedł czas powrotów.

Konferencję uważamy za bardzo udaną. Wróciliśmy z głowami pełnymi nowych pomysłów, umocnieni wymianą doświadczeń z grupą administratorów oraz programistów.

Instalowanie modułu php pdo_oci może przyprawaić administratorów o ból głowy a google podaje wiele rozwiązań, które w więszości dotyczą starszych wersji oracle lub kończą się niepowodzeniem. W przypadku bazy danych Oracle Express Edition i modułu pdo_oci instalacja przebiega w następujący sposób:

• Ściągamy pakiety: oracle-instantclient-basic-10.2.0.4-1.x86_64.rpm oraz oracle-instantclient-devel-10.2.0.4-1.x86_64.rpm ze strony oracle
• Instalujemy pakiety:
  rpm -Uvh oracle-instantclient-basic-10.2.0.4-1.x86_64.rpm
rpm -Uvh oracle-instantclient-devel-10.2.0.4-1.x86_64.rpm
• W przypadku dystrybucji 64-bit w  katalogach /usr/lib/oracle/10.2.0.4/ oraz /usr/include/oracle/10.2.0.4/ tworzymy symlink client do katalogu client64:
  ln -s client64 client
• Ściągamy moduł pdo_oci za pomocą pecl-a i rozpakowujemy źródła:
  pecl download PDO_OCI
tar zxf PDO_OCI-1.0.tgz
• Po rozpakowaniu źródeł wchodzimy do katalogu PDO_OCI-1.0 i tworzymy środowisko do zbudowania modułu php:
  cd PDO_OCI-1.0 && phpize
• Budujemy moduł pdo_oci:
  ./configure --with-pdo-oci=instantclient,/usr,10.2.0.4
make && make test
• Zbudowany moduł pdo_oci.so kompiujemy do katalogu z modułami php:
  cp modules/pdo_oci.so /usr/lib/php5/extensions
• Ostatnim etapem jest dodanie biblioteki do php.ini oraz restart serwera www
  echo "extension=pdo_oci.so" >> php.ini
/etc/init.d/apache2 restart

Każdemu zdarza się popełniać błędy, nawet programistom o czym można przekonać się przeglądając listy z dziurami zabezpieczeń, np. Secunia Advisories. Błędy bezpieczeństwa to nie jedyny problem, z którym administrator musi się zmagać w codziennej pracy.

W ostatnim czasie na kilku produkcyjnych maszynach zaczęły się problemy z obciążeniem oraz błędami systemu plików, które skutkowały automatycznym przemontowaniem partycji w trybie tylko do odczytu co następnie prowadziło do destabilizacji maszyny przez procesy, które chciały coś na tej partycji zapisać. Rzut okiem na logi serwera oraz przeszukanie redhatowego bugtraqua i oto mamy punkty zaczepienia.

Postępowanie w takich sytuacjach jest bardzo proste:
1. Należy zachować spokój, gdyż nieprzemyślane działanie może przynieść więcej szkody niż pożytku
2. Przyjrzeć się dokładnie logom serwera, w tym przypadku w logach powtarzają się wpisy:
Jul 8 10:16:14 erwin kernel: EXT3-fs error (device md4): ext3_lookup:
unlinked inode 99189142 in dir #99188744
Jul 8 10:16:14 erwin kernel: Aborting journal on device md4.
Jul 8 10:16:14 erwin kernel: __journal_remove_journal_head: freeing
b_committed_data
Jul 8 10:16:14 erwin last message repeated 2 times
Jul 8 10:16:14 erwin kernel: ext3_abort called.
Jul 8 10:16:14 erwin kernel: EXT3-fs error (device md4):
ext3_journal_start_sb: Detected aborted journal
Jul 8 10:16:14 erwin kernel: Remounting filesystem read-only
3. Jak widać problem występuje z journalem systemu plików (jest on uszkodzony), więc należy go przywrócić:
- uruchamiamy system w single mode (należy dodać parametr single do wiersza parametrów kernela w bootloaderze
- należy odmontować uszkodzoną partycję, np. umount /dev/md4
- usuwamy uszkodzony journal: tune2fs -O ^has_journal /dev/md4
- sprawdzamy system plików co może trochę potrwać: e2fsck -fy /dev/md4
- zakładamy nowy journal: tune2sf -j /dev/md4
- ponownie sprawdzamy system plików: fsck -y /dev/md4
- reboot
4. Jeśli wszystko przebiegło bez problemów to możemy się cieszyć z kolejnego rozwiązanego problemu.