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.