Błąd przy instalacji Traca: No such file or directory: '/var/lib/trac/.egg-cache/VERSION

Co robimy:
Dodajemy do konfiguracji vhosta w apache'u:

PythonOption PYTHON_EGG_CACHE /tmp

Jeżeli w katalogu z projektami istnieje katalog .egg-cache - usuwamy go. Później wystarczy restart apache'a.

Zapisywanie uprawnień do plików i katalogów

Czasami przydatną rzeczą okazuje się archiwizacja uprawnień do plików i katalogów. Możemy to zrobić komendą:

# getfacl nazwa_pliku

Możemy spróbować zdobyc uprawnienia rekurecyjnie w całym podkatalogu, a wynik zapisać w pliku:

# getfacl katalog > /tmp/files.acl

Jeżeli z jakiegoś powodu potrzebujemy przywrócić uprawnienia do poprzednich - robimy to komendą:

# setfacl --restore=/tmp/files.acl

Zadanie domowe:
- przeglądnąć man setfacl i getfacl
- potestować we własnym zakresie różne opcje(jak zawsze)

ORA-01658: unable to create INITIAL extent for segment in tablespace string

Brakło miejsca przy rozszerzaniu pliku należącego do przestrzeni tabel (TABLE SPACE). Jeżeli została użyta opcja opcja AUTOEXTEND (przy tworzeniu takiego plikunp. ALTER DATABASE DATAFILE 'pelna_sciezka_do_pliku' AUTOEXTEND ON NEXT 10M;) - to prawdopodobnie zabrakło miejsca na partycji, w której znajduje się powyższy plik. W przeciwnym razie powodem jest przekroczenie rozmiaru pliku (gdy nie używamy opcji AUTOEXTEND) - wtedy musimy ręcznie zwiększyć jego rozmiar, np. tak:

ALTER DATABASE DATAFILE 'pelna_sciezka_do_pliku' RESIZE 500M;

Gentoo - problemy przy kompilacji KDE4 - błąd libtool: link: `/usr/lib/libogg.la' is not a valid libtool archive

Ponieważ pakiety KDE4 w Gentoo w końcu zostały zakwalifikowane jak pakiety stabilne - postanowiłem sobie zaktualizować system instalując przy okazji środowisko grficzne KDE4. Niestety przy kompilacji pakietu pojawia się powyższy błąd:

/bin/grep: /usr/lib/libogg.la: No such file or directory
/bin/sed: can't read /usr/lib/libogg.la: No such file or directory
libtool: link: `/usr/lib/libogg.la' is not a valid libtool archive
make: *** [libgstvorbis.la] Error 1
*
* ERROR: media-plugins/gst-plugins-vorbis-0.10.23 failed.
* Call stack:
* ebuild.sh, line 49: Called src_compile
* environment, line 2289: Called gst-plugins-base_src_compile
* environment, line 1665: Called die
* The specific snippet of code:
* emake || die "compile failure"
* The die message:
* compile failure
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/log/portage/media-plugins:gst-plugins-vorbis-0.10.23:20091113-071732.log'.
* The ebuild environment file is located at '/var/tmp/portage/media-plugins/gst-plugins-vorbis-0.10.23/temp/environment'.
*

Żeby pozbyć się problemów instalujemy pakiet dev-util/lafilefixer, a następnie go uruchamiamy:

# lafilefixer --justfixit

Następnie można kontynuować aktualizację.

Zadanie domowe:
- poszukać informacji o plikach .la
- przeglądnąć dowolny plik libtool .la

Jak sprawdzić z skąd instancja Oracle'a wzięła parametry startowe?

Z którego typu parametrów uruchomieniowych korzysta twoja instancja? Zmieniłeś je w PFILE'u a instancja dalej się uruchamia ze starymi ustawieniami - więc zapewne jest to SPFILE? Nie chcesz zgadywać?

Uruchamiamy konsolę:

sqlplus / as sysdba
SELECT DECODE (value, NULL,'PFILE', 'SPFILE') "Init File Type" FROM v$parameter WHERE name = 'spfile';

I już wiemy.
Ogólnie zasada jest taka - wartość value = NULL oznacza, że baza nie korzysta z określonego typu pliku inicjalizacyjnego. Jeżeli w obydwu przypadkach wartość kolumny VALUE jest NULLem - to baza danych używa PFILE.

Możemy też łatwo znaleźć lokalizację pliku za pomocą:

select value from v$parameter where name like 'spfile';

lub

SHOW PARAMETER SPFILE;

Secure FTP - bezpieczne FTP w praktyce

Nie mam zamiaru opowiadać tu o słabościach protokołu FTP i problemach związanych z konfiguracją takowego serwera. Lepiej pójść na skróty i skorzystać z gotowego, lepszego i prostszego rozwiązania (KISS) jakim jest SFTP. Mając zainstalowany serwer SSH (prawie na pewno będzie to openSSH) dostajemy taką możliwość gratis.

Najprostszym a zarazem najszybszym sposobem jest stworzenie konta i ustawienie domyślnego shella na binarkę serwera sftp - najczęściej jest to sftp-server (w debianie - /usr/lib/sftp-server, w Gentoo - /usr/lib/misc/sftp-server, w innych - poszukajcie sobie sami). Zakładamy konto:

useradd -m -s /usr/lib/misc/sftp-server username

Pozostaje jeszcze dodać sftp-server do listy dozwolonych powłok (shell) zgłoszeniowych (debilne tłumaczenie - login shells), np. tak:

echo "/usr/lib/misc/sftp-server" >> /etc/shells

Szybko i prosto zdefiniowaliśmy serwer SFTP. Jedyne co można zarzucić temu rozwiązaniu to możliwość poruszania się użytkownika po całym filesystemie - w miarę oczywiście posiadanych uprawnień - a tego nie zawsze chcemy.

Drugim sposobem, który jest może trudniejszy w konfguracji jest udostępnienie jedynie dostępu do serwera sftp z możliwością chrootowania katalogu użytkownika (chroot).
Zmieniamy w /etc/ssh/sshd_config

Subsystem sftp internal-sftp

# These lines must appear at the *end* of sshd_config
Match User username
ChrootDirectory /home/userhome
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no

Restartujemy sshd (/etc/init.d/sshd restart) i już.
Waryo pamiętać o ustawieniu shella użytkownika na /sbin/nologin

Bardzo ważne jest ustawienie właściciela i grupy na katalogu do którego będzie ograniczone środowisko robocze użytkownika na root oraz ustawienie odpowiednich uprawnień aby umożliwić użytkownikowi zapis w tym katalogu.

ps. Zamiast Match User można użyć np. Match Group - polecam poczytanie manuala sshd.

Oracle na Centosie

Zainstalowałem sobie testowego Oracle'a na wirtualnej maszynie. Przy instalacji patch'a wywalił mi komunikat:

[root@centosik Disk1]# ./runInstaller -silent -responseFile response/patchset.rsp
Starting Oracle Universal Installer...

Checking installer requirements...

Checking operating system version: must be redhat-3, SuSE-9, SuSE-10, redhat-4, redhat-5, UnitedLinux-1.0, asianux-1, asianux-2 or asianux-3
Failed <<<<

Exiting Oracle Universal Installer, log for this session can be found at /home/oracle/oraInventory/logs/installActions2009-11-01_12-56-26PM.log

Jak się można domyślić "enterprajsowe" sprawdzenie dystrybucji to naprawdę skomplikowane zadanie.
Jak uruchomić patcha mimo wszystko? A na przykład tak:

echo "Red Hat Linux release 5" > /etc/redhat-release

i już działa - dystrybucja jest w porządku - "enterprajs" rządzi

ps. wszystko jak się wydaje zależy od wersji oracle. Swego czasu musiałem mieć w pliku redhat-release wpis np. redhat-4