Problemy z instalacją sun-jdk na Gentoo

Po ostatnich zmianach/aktualizacjach portage'a przy próbie aktualizacji systemu portage wyrzuca do listy pakietów wymagających zainstalowania pakiet dev-java/icedtea6-bin. Próba instalacji pakietu sun-jdk wyrzuca błąd:

[ebuild R ] virtual/jdk-1.6.0 0 kB

Total: 5 packages (1 upgrade, 3 new, 1 reinstall), Size of downloads: 0 kB

!!! The following installed packages are masked:
- dev-java/sun-jdk-1.6.0.17 (masked by: dlj-1.1 license(s))
A copy of the 'dlj-1.1' license is located at '/usr/portage/licenses/dlj-1.1'.

- dev-java/sun-jdk-1.5.0.22 (masked by: dlj-1.1 license(s))
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

Ponieważ na swoim serwerze korzystam z java'y SUNa i nie zamierzam instalować innych implementacji musiałem rozwiązać skutecznie ten problem.
Jak się okazało zmiany pojawiły się w poertage'u. Obecnie akceptacja lista licencji akceptowanych trzymana jest w zmiennej ACCEPT_LICENSE. Jest kilka sposobów na ustawienie tej zmiennej:

- wpis pliku make.conf

ACCEPT_LICENSE="dlj-1.1"

lub mniej szczegółowo

ACCEPT_LICENSE="*"

- wpis w pliku /etc/portage/package.license, np. tak:

games-fps/quake3-bin Q3AEULA
games-fps/quake3-data Q3AEULA
dev-java/sun-jdk dlj-1.1

- definicja zmiennej przy instalacji pakietu:

ACCEPT_LICENSE="dlj-1.1" emerge -av sun-jdk

i już. Teraz z powrotem mogę korzystać z sun-jdk a pakiet icedtea-jdk nie próbuje się zainstalować przez zależność z wirtualnego pakietu virtual/jdk.

Monitoring stanu replikacji serwerów LDAP

Po ostatniej aktualizacji OpenLDAP okazało się, że nie ma wsparcia dla metody replikacji danych LDAP na slave'y. Skorzystałem z nowego mechanizmu refreshAndPolling, o którym w tej chwili nie mam czasu się rozpisywać (może innym razem). Problemem o którym chciałem napisać jest - jak w temacie - monitorowanie stanu replikacji. Czyli - czy wszystkie dane propagują się poprawnie na serwery podrzędne (slave)?
Do czasu migracji sprawdzałem to za pomocą parsowania logu demona slurpd (odpowiedzialnego w OpenLDAP 2.3 za replikację na slave'y) - niestety w 2.4 takiej możliwości już nie ma. Hmm - choć zapewne jakby się uparł - toż to linux - to by się dało. Ponieważ zajęłoby to sporo czasu i było dość zawiłe w implementacji skorzystałem z nowej i prostszej możliwości jaką daje analiza atrybutu contextCSN w baseDN. Teraz na każdym serwerze podrzędnym można wykonać sprawdzenie stanu poprzez odpytanie o numer contextCSN:

master$ ldapsearch -x -LLL -H ldap://master:389 -s base -b 'dc=linuxway,dc=eu' contextCSN
dn: dc=linuxway,dc=eu contextCSN: 20101025222436.834813Z&000000;000#000000

slave$ ldapsearch -x -LLL -H ldap://slave:389 -s base -b 'dc=linuxway,dc=eu' contextCSN
dn: dc=linuxway,dc=eu contextCSN: 20101025222436.834813Z&000000;000#000000

i już jeśli contextCSN na każdym z hostów jest identyczny z tym na masterze = replikacja działa.

Aktualizacja openldap

Ostatnio pojawiła sie w portage'u wersja pakietu Openldap z nowej gałęzi - 2.4. Chciałem na jej przykładzie omówić politykę aktualizacji stosowaną w Gentoo w wypadku znaczących zmian w funkcjonalności nowej wersji pakietu.

Próba aktualizacji paczki z wersji 2.3 do 2.4 zakończona będzie niepowodzeniem - dlaczego?
Ano - pakiet używa nowego formatu bazy danych - przez co obecne w systemie bazy OpenLDAP w wersji 2.3 nie pozwolą na poprawne działanie serwera wersji 2.4. Dzięki takiemu podejściu nie zabijemy nieświadomie swojego systemu. Zobaczmy najpeirw jak to wygląda w praktyce:

y ~ # emerge -av openldap

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ] net-nds/openldap-2.4.19-r1 [2.3.43] USE="berkdb crypt kerberos perl samba sasl ssl -cxx% -debug -experimental% -gnutls% -icu% -iodbc% -ipv6 -minimal -odbc -overlays (-selinux) -slp -smbkrb5passwd -syslog% -tcpd (-gdbm%*)" 0 kB

Total: 1 package (1 upgrade), Size of downloads: 0 kB

Would you like to merge these packages? [Yes/No]

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) net-nds/openldap-2.4.19-r1
* openldap-2.4.19.tgz RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* checking ebuild checksums ;-) ... [ ok ]
* checking auxfile checksums ;-) ... [ ok ]
* checking miscfile checksums ;-) ... [ ok ]
>>> cfg-update-1.8.2-r1: Creating checksum index...
*
* Scanning datadir(s) from slapd.conf and
* the default installdir for Versiontags
* (/var/lib/openldap-data may appear twice)
*
* - Checking /var/lib/openldap-data...
* Found Versiontag in /var/lib/openldap-data
* Versiontag doesn't match current major release!
* Versiontag says other major and you (probably) have datafiles!

*
* A (possible old) installation of OpenLDAP was detected,
* installation will not proceed for now.
*
* As major version upgrades can corrupt your database,
* you need to dump your database and re-create it afterwards.
*
* Additionally, rebuilding against different major versions of the
* sys-libs/db libraries will cause your database to be inaccessible.
*
* 1. /etc/init.d/slurpd stop ; /etc/init.d/slapd stop
* 2. slapcat -l /root/ldapdump.1262979255.raw
* 3. egrep -v '^entryCSN:' /root/ldapdump.1262979255
* 4. mv /var/lib/openldap-data/ /var/lib/openldap-data-backup/
* 5. emerge --update \=net-nds/openldap-2.4.19-r1
* 6. etc-update, and ensure that you apply the changes
* 7. slapadd -l /root/ldapdump.1262979255
* 8. chown ldap:ldap /var/lib/openldap-data/*
* 9. /etc/init.d/slapd start
* 10. check that your data is intact.
* 11. set up the new replication system.
*
*
* ERROR: net-nds/openldap-2.4.19-r1 failed.
* Call stack:
* ebuild.sh, line 49: Called pkg_setup
* openldap-2.4.19-r1.ebuild, line 213: Called openldap_find_versiontags
* openldap-2.4.19-r1.ebuild, line 99: Called openldap_upgrade_howto
* openldap-2.4.19-r1.ebuild, line 197: Called die
* The specific snippet of code:
* die "You need to upgrade your database first"
* The die message:
* You need to upgrade your database first
*
* 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/net-nds:openldap-2.4.19-r1:20100108-193411.log'.
* The ebuild environment file is located at '/var/tmp/portage/net-nds/openldap-2.4.19-r1/temp/die.env'.
*

>>> Failed to emerge net-nds/openldap-2.4.19-r1, Log file:

>>> '/var/log/portage/net-nds:openldap-2.4.19-r1:20100108-193411.log'

Jak widać - próba zakończona niepowodzeniem. Dodatkowo - co ma miejsce w wypadku większości pakietów - dostajemy gotową instrukcję/procedurę upgrade'u obecnej bazy LDAP do nowej wersji.

Zainteresowanym pozostawiam kwestię sprawdzenia w jaki sposób zrobiona jest powyźsza blokada - na pewno warto przyjrzeć się plikowi ebuild - /usr/portage/net-nds/openldap/openldap-2.4.19-r1.ebuild

Dalej - to jest już proste - instrukcja prowadzi nas "za rączkę" - najlepiej samemu to przerobić.

Na inny raz pozostawiam kwestię LDAPa i jego zastosowań

TIPS & TRICKS
Ponieważ domyślnie nowy pakiet (w tym wypadku chodzi o wersję 2.4) można skompilować dopiero po wyłączeniu aktualnej wersji serwisu (2.3) - co może zając dobrych parę minut - warto skorzystać ze sztuczki umożliwiającej skompilowanie pakietu bez jego instalacji (przełącznik --buildpkgonly):

# FORCE_UPGRADE=1 emerge -av --buildpkgonly openldap

Ważne w tym wypadku jest ustawienie wartości zmiennej FORCE_UPGRADE przy wywołaniu polecenia emerge. Powyższa komenda skompiluje pakiet - a po kompilacji umieści go w paczce .tbz w /usr/portage/packages (domyślnie).

Dzięki temu zabiegowi po wyłączeniu starego serwisu - możemy szybko zainstalować nową wersję openldapa z paczki tbz:

# emerge -av --usepkgonly openldap

Migracja przebiegnie wtedy bardzo sprawnie i praktycznie bez większych zakłóceń. Warto stosować to rozwiązanie przy tego typu trudnych aktualizacjach.