Moje środowisko:

• System operacyjny: GNU/Linux
• Dystrybucja: Gentoo Base System release 2.0.2
• Serwer WWW: Lighttpd
• Bacula: 5.0.3 (bacula-gui)
• Perl: 5.12.3

1. Przygotowanie środowiska

Zakładam, że coś tam w systemie już jest, więc o np. Perl nie piszę. Z dodatków będzie:

dev-perl/GD dev-perl/GDGraph dev-perl/HTML-Template perl-core/CGI dev-perl/Expect dev-perl/Time-modules dev-perl/Date-Calc

Do tego flagi:

dev-perl/GD gif jpeg png truetype
media-libs/gd truetype

2. Instalacja Bweb

Jeśli mamy już działające środowisko Bacula (director, storage i client), wystarczy pobrać paczkę bacula-gui (na chwilę obecną 5.0.3) i z niej wykonać instalację Bweb.
Po rozpakowaniu (tar xzvf bacula-gui-5.0.3.tar.gz -C <path>) zalecam przejrzenie pliku <path>/bweb/INSTALL. W skrócie instalacja wygląda jak poniżej (przy czym na początku tylko testy środowiska, więc nie jest to wymagane).

cd <path>bweb/lib
../cgi/bweb.pl
../cgi/bgraph.pl

Dalej modyfikujemy bazę :

cd <path>bweb
mysql bacula < script/bweb-mysql.sql

3. Uruchomienie

Na koniec uruchamiamy lighttpd (musi być wcześniej zainstalowany) za pomocą skryptu ./script/starthttp i łączymy się z maszyną dowolną przeglądarką na porcie 9180 lub modyfikujemy konfigurację lighttpd dodając stosowne dyrektywy z pliku script/httpd.conf
Niezależnie od tego, którą drogę wybierzemy, pozostaje jeszcze skonfigurowanie połączeń z bazą. Albo poprzez edycję pliku bweb.conf, albo na stronie Bweb.

Statystyki do raportu tygodniowego

Zacznę od dhcpcd, o którym pisałem wcześniej w kontekście ipv4ll (aka. zeroconf). Aktualna wersja dostępna dla Gentoo – 5.2.10 nie wspiera opcji timeout dla interfejsu, jedynie globalnie (definiowane w dhcpcd.conf). Po dyskusji z Royem Marples zostało to poprawione, jednakże zanim trafi do stabilnej wersji, a ta do drzewa portage, trochę czasu minie.

Poprawki mamy, możemy więc skompilować oprogramowanie ze źródeł, zainstalować na miejsce aktualnego i używać do czasu aktualizacji. Można też – bardziej elegancko, przygotować własny ebuild i zaktualizować program korzystając z emerge. W przypadku wspomnianego net-misc/dhcpcd poprawka może wyglądać tak (zmiana src_unpack) w pliku ebuild, który dla czytelności możemy oznaczyć kolejnym numerkiem, np. dhcpcd-5.2.11-r1.ebuild):

src_unpack() {
unpack ${A}
cd "${S}"

if ! use zeroconf; then
elog "Disabling zeroconf support"
{
echo
echo "# dhcpcd ebuild requested no zeroconf"
echo "noipv4ll"
} >> dhcpcd.conf
fi

# patches go here...
epatch "${FILESDIR}"/dhcpcd-5.2.11-tmout.diff
}


A plik dhcpcd-5.2.11-tmout.diff może mieć taką postać:

--- /tmp/dhcpcd-5.2.11/dhcpcd.c 2011-02-04 15:56:03.000000000 +0100
+++ /tmp/dhcpcd.c 2011-03-30 09:02:44.000000000 +0200
@@ -2011,17 +2011,20 @@ main(int argc, char **argv)
}
}
}
+ if (options & DHCPCD_MASTER)
+ i = if_options->timeout;
+ else
+ i = ifaces->state->options->timeout;
if (opt == 0 &&
options & DHCPCD_LINK &&
!(options & DHCPCD_WAITIP))
{
syslog(LOG_WARNING, "no interfaces have a carrier");
daemonise();
- } else if (if_options->timeout > 0) {
+ } else if (i > 0) {
if (options & DHCPCD_IPV4LL)
options |= DHCPCD_TIMEOUT_IPV4LL;
- add_timeout_sec(if_options->timeout,
- handle_exit_timeout, NULL);
+ add_timeout_sec(i, handle_exit_timeout, NULL);
}
}
free_options(if_options);


Pliki można ściągnąć z mojego zgłoszenia w Gentoo’s Bugzilla.

Jeśli zostawimy to wszystko w oryginalnych katalogach (w /usr/portage) podczas kolejnej synchronizacji zostanie usunięte. Jeżeli więc poprawki nie mają charakteru okazjonalnego, możemy zabezpieczyć się kopiując wybraną gałąź drzewa w osobne miejsce i konfigurując zmienna PORTDIR_OVERLAY w /etc/make.conf (musi wskazywać na nasze drzewo). Pamiętać należy, że struktura naszego własnego drzewa musi być podobna do oryginalnego.

localhost ~ # mkdir -p /usr/local/portage/net-misc
localhost ~ # cp -rp /usr/portage/net-misc/dhcpcd /usr/local/portage/net-misc/
localhost ~ # echo "PORTDIR_OVERLAY=\"/root/portage\"" >> /etc/make.conf

Po takim zabiegu widać będzie już nasze własne drzewo przy kompilacji pakietu:

localhost ~ # emerge -pv net-misc/dhcpcd

These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] net-misc/dhcpcd-5.2.10-r3 USE="zeroconf" 0 kB [1]

Total: 1 package (1 new), Size of downloads: 0 kB
Portage tree and overlays:
[0] /usr/portage
[1] /usr/local/portage

W przypadku aktualizacji wygląda to tak:

localhost dhcpcd # emerge -pv net-misc/dhcpcd

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

Calculating dependencies... done!
[ebuild U ] net-misc/dhcpcd-5.2.10-r3 [5.2.10-r2] USE="zeroconf" 0 kB [0=>1]

Total: 1 package (1 upgrade), Size of downloads: 0 kB
Portage tree and overlays:
[0] /usr/portage
[1] /root/portage

Przeczytaj więcej:

• HOWTO: Installing 3rd Party Ebuilds [http://www.gentoo-wiki.info/HOWTO_Installing_3rd_Party_Ebuilds]
• Ebuild HOWTO [http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1]
• HOWTO: Local Rsync Mirror http://www.gentoo-wiki.info/HOWTO_Local_Rsync_Mirror

Q: A co jeśli nie robimy tego na bieżąco?
A: No może być różnica w EAPI (Ebuild Application Programming Interface), ale zazwyczaj aktualizacja sys-apps/portage wcześniej rozwiąże sprawę.

Q: A co jeśli nie aktualizowaliśmy dość długo?
A: Jak wyżej. W przypadku problemów można spróbować przebudować sys-apps/portage bez zależności (emerge --nodep portage), to samo zrobić z dev-lang/python, a następnie przebudować ‘normalnie’ oba te pakiety.

Q: A co jeśli bardzo, bardzo mocno zapuściliśmy nasz system?
A: Huh. Czeka nas droga przez mękę. Zadajmy sobie pytanie czy w ogóle chcemy to robić. Jeśli to system wewnętrzny, może warto kierować się zasadą g… (jak działa i nie śmierdzi, to nie ruszaj)? Gorzej jak chcemy coś doinstalować, źródeł starych wersji nie ma, drzewo aktualne wymaga EAPI >= 3. Wtedy wyglądać to może tak:

dolly ~ # cat /etc/gentoo-release
Gentoo Base System release 1.12.9
dolly ~ # uname -a
Linux dolly 2.6.20-gentoo #1 PREEMPT Thu Feb 8 10:12:04 CET 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
dolly ~ # emerge --info
Portage 2.1.2-r9 (default/linux/x86/10.0, gcc-4.1.2, glibc-2.5-r0, 2.6.20-gentoo i686)
=================================================================
System uname: 2.6.20-gentoo i686 Pentium III (Coppermine)
Gentoo Base System release 1.12.9
dolly ~ # python -V
Python 2.4.3

No cóż. Ja ciągle wierzę, że da się z tego wybrnąć (choć walczę już dość długo). Po pierwsze profil, który był kiedyś już dawno jest zapomniany.

dolly ~ # eselect profile list
Available profile symlink targets:
[1] default/linux/x86/10.0 *
dolly ~ # emerge portage
Calculating dependencies \
!!! All ebuilds that could satisfy "portage" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/portage-2.1.6.7 (masked by: profile)
- sys-apps/portage-9999 (masked by: required EAPI 2, supported EAPI 0)
- sys-apps/portage-2.1.8.3 (masked by: required EAPI 2, supported EAPI 0)
- sys-apps/portage-2.2.0_alpha26 (masked by: required EAPI 2, supported EAPI 0)
- sys-apps/portage-2.1.9.25 (masked by: required EAPI 2, supported EAPI 0)
- sys-apps/portage-2.1.6.13 (masked by: required EAPI 1, supported EAPI 0)
- sys-apps/portage-2.1.9.42 (masked by: required EAPI 2, supported EAPI 0)
For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.


Spróbujmy zatem innego (to da się zrobić tylko ręcznie):

dolly ~ # rm /etc/make.profile
dolly ~ # ln -s /usr/portage/profiles/default/linux/x86/2008.0 /etc/make.profile
dolly ~ # emerge -pv portage
!!! Your current profile is deprecated and not supported anymore.
!!! Please upgrade to the following profile if possible:
default/linux/x86/10.0
To upgrade do the following steps:
# Check 'eselect profile list'.
# Find the number that corresponds with the default/linux/x86/10.0 profile.
# Use 'eselect profile set ' to set a new /etc/make.profile symlink.
#
# Reference: http://www.gentoo.org/doc/en/gentoo-upgrading.xml
# See: "General instructions" in Section 3. "Profile updating instructions"
These are the packages that would be merged, in order:
Calculating dependencies |
!!! All ebuilds that could satisfy ">=app-admin/eselect-python-20091230" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-admin/eselect-python-20100321 (masked by: required EAPI 1, supported EAPI 0)
- app-admin/eselect-python-20091230 (masked by: required EAPI 1, supported EAPI 0)
- app-admin/eselect-python-99999999 (masked by: required EAPI 2, supported EAPI 0)
For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.
(dependency required by "sys-apps/portage-2.1.6.7" [ebuild])


Jesteśmy już bliżej, ale nadal się nie udaje. To może python bez zależności?

dolly ~ # emerge --nodep python
* IMPORTANT: 5 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.
>>> Emerging (1 of 1) dev-lang/python-2.6.6-r2
* Python-2.6.6.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* python-gentoo-patches-2.6.6-r2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
/usr/portage/eclass/python.eclass: line 63: syntax error in conditional expression: unexpected token `('
/usr/portage/eclass/python.eclass: line 63: syntax error near `^(('
/usr/portage/eclass/python.eclass: line 63: ` if [[ "${version_components_groups}" =~ ^((\!)?[[:alnum:]_-]+\?\ )?${version_components_group_regex}(\ ${version_components_group_regex})?$ ]]; then'
*
* ERROR: dev-lang/python-2.6.6-r2 failed.
* Call stack:
* ebuild.sh, line 1867: Called source '/usr/portage/dev-lang/python/python-2.6.6-r2.ebuild'
* python-2.6.6-r2.ebuild, line 8: Called inherit 'autotools' 'eutils' 'flag-o-matic' 'multilib' 'python' 'toolchain-funcs'
* ebuild.sh, line 1224: Called die
* The specific snippet of code:
* qa_source "$location" || die "died sourcing $location in inherit()"
* The die message:
* died sourcing /usr/portage/eclass/python.eclass in inherit()
*
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/tmp/portage/dev-lang/python-2.6.6-r2/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-lang/python-2.6.6-r2/temp/die.env'.
*
>>> Failed to emerge dev-lang/python-2.6.6-r2, Log file:
>>> '/var/tmp/portage/dev-lang/python-2.6.6-r2/temp/build.log'


E-e! To też nie zadziała. A jakby tak przenieść portage ze świeższego systemu – to nie jest trudne.

tar cvf /tmp/portage.tar `qlist sys-apps/portage`

Takie archiwum rozpakowujemy na docelowej maszynie i walczymy dalej.

Niestety w moim przypadku nie powiodło się. To może dorzucimy python’a? Przenosimy w sposób jak powyżej, dla bezpieczeństwa rozpakować możemy gdzieś na boku, w $PATH wstawiamy ścieżkę do katalogu z binariami, dodatkowo ustawiamy zmienną $LD_LIBRARY_PATH na katalog lib/ i mamy świeższe oprogramowanie do dyspozycji.
No już prawie witam się z gąską… Dalej klapa. Ale broni nie złożę tak łatwo!

Drogi czytelniku! Jeśli miałeś podobne problemy i je rozwiązałeś, a jednocześnie chcesz mi popsuć krótki weekend, wpisz proszę swoje uwagi w komentarzu poniżej.

localhost ~ # qsize -b openssh nano
net-misc/openssh-5.8_p1: 21 files, 15 non-files, 2077068 bytes
app-editors/nano-2.2.5: 83 files, 79 non-files, 347806 bytes

To samo możemy uzyskać następującym łamańcem:

ls -l `qlist openssh` 2>/dev/null|awk '{SUM += $5} END {print SUM}'

Co to robi? Korzystając z qlist (również z portage-utils) wyświetlam listę plików przynależnych do danego pakietu, a następnie ich rozmiar (piąta kolumna zwracana przez ls -l) sumuję za pomocą awk.
To 2>/dev/null jest niezbędne jak ktoś ręcznie usuwa pliki. qlist o tym nie wie. qsize zwraca dokładnie ten sam wynik, ale robi to szybciej.

Oprócz qlist i qsize w portage-utils jest jeszcze wiele innych ciekawych i szybkich narzędzi. Np. qfile sprawdzi nam czy dany plik należy do jakiegoś pakietu (czyli odwrotnie do qlist), qsearch szybko poszuka nam pakietu, a quse pokaże który pakiet skompilowany jest z podaną flagą USE.

Po opis pozostałych programów odsyłam do dokumentacji.

q --help
qatom <pkg>           : split atom strings
qcache <action> <args> : search the metadata cache
qcheck <pkgname>       : verify integrity of installed packages
qdepends <pkgname>       : show dependency info
qfile <filename>      : list all pkgs owning files
qglsa <action> <list> : check GLSAs against system
qgrep <misc args>     : grep in ebuilds
qlist <pkgname>       : list files owned by pkgname
qlop <pkgname>       : emerge log analyzer
qmerge <pkgnames>      : fetch and merge binary package
qpkg <misc args>     : manipulate Gentoo binpkgs
qsearch <regex>         : search pkgname/desc
qsize <pkgname>       : calculate size usage
qtbz2 <misc args>     : manipulate tbz2 packages
quse <useflag>       : find pkgs using useflags
qxpak <misc args>     : manipulate xpak archives

Za co jest odpowiedzialny? Wskazujemy w nim wykorzystanie systemu plików tak, by mke2fs mógł optymalnie dobrać parametry (nie musimy tego robić doświadczalnie jak ja wcześniej). Te typy są zdefiniowane w pliku /etc/mke2fs.conf. Jak podaje dokumentacja, system plików o rozmiarze poniżej 3 MB zostanie potraktowany jako floppy, powyżej 3 MB, a poniżej 512 MB – small, a większe dostaną domyślne wartości (można zdefiniować dla nich typ default).

Podtrzymuję, że dysk do 4 GB (a może 8 GB) to też typ small i w przypadku Gentoo Linux warto zmniejszyć bytes/inode ratio (a na pewno jeśli chcemy trzymać portage).

[...]
1285757303: >>> emerge (10 of 11) net-dns/bind-9.7.1_p2 to /
1285757305: === (10 of 11) Cleaning (net-dns/bind-9.7.1_p2::/usr/portage/net-dns/bind/bind-9.7.1_p2.ebuild)
1285757305: === (10 of 11) Compiling/Merging (net-dns/bind-9.7.1_p2::/usr/portage/net-dns/bind/bind-9.7.1_p2.ebuild)
1285757568: === (10 of 11) Merging (net-dns/bind-9.7.1_p2::/usr/portage/net-dns/bind/bind-9.7.1_p2.ebuild)
1285757573: >>> AUTOCLEAN: net-dns/bind:0
1285757573: === Unmerging... (net-dns/bind-9.4.3_p5)
1285757574: >>> unmerge success: net-dns/bind-9.4.3_p5
1285757576: === (10 of 11) Post-Build Cleaning (net-dns/bind-9.7.1_p2::/usr/portage/net-dns/bind/bind-9.7.1_p2.ebuild)
1285757576: ::: completed emerge (10 of 11) net-dns/bind-9.7.1_p2 to /
[...]

etc-update jakoś przeszło, ale restart nie udał się, bo chroot dir okazał się inconsistent.
Wykonałem więc zalecane wskazówki, ale nie skupiłem się na wyniku, bo zajęty byłem rozmową o pogodzie czy kobietach. A wynik wyglądał tak:

dns ~ # emerge --config net-dns/bind

Configuring pkg...

* NOTE: As of net-dns/bind-9.4.3_p5-r1 the chroot part of the init-script got some major changes!
*
* /chroot/dns already exists... some things might become overridden
* press CTRL+C if you don't want to continue

Potem coś tam jeszcze, co nadpisało powyższe linijki, więc nie dotarły do mnie za pierwszym razem. Próba restartu usługi i… $!#$!%#@%! – coś nie działa. Przegląd konfiguracji i jeszcze bardziej ~^%$!%^$#! Nie ma mojej starej konfiguracji! Przecież tylko might become overridden!

Tylko spokojnie. Sytuacja do opanowania.
Myślicie, że była poprawna kopia zapasowa? Ja też tak myślałem.

Jest ciepło, ale nie gorąco. A może jednak? Przecież jest zapasowy serwer nazw, z którego można sobie ściągnąć wszystkie strefy.
Jest, ale nie pozwala na AXFR. Huh. Kontaktu z administratorami nie ma (ja niestety nim nie zarządzam).

Dobra, sprawdźmy co robią te komendy, bo może jednak gdzieś na boku zrobiły kopię.

W pliku /usr/portage/net-dns/bind/bind-9.7.1_p2.ebuild funkcja pkg_config() wygląda następująco:

294 pkg_config() {
295 CHROOT=$(source /etc/conf.d/named 2>/dev/null; echo ${CHROOT})
[...]
303 if [[ -d "${CHROOT}" ]]; then
304 ewarn "NOTE: As of net-dns/bind-9.4.3_p5-r1 the chroot part of the init-script got some major changes!"
305 ewarn
306 ewarn "${CHROOT} already exists... some things might become overridden"
307 ewarn "press CTRL+C if you don't want to continue"
308 sleep 10
309 fi
[...]
337 }


O! czyli miałem 10 sekund na reakcję. Poza tym niewiele ciekawego w tym pliku (ani słowa o usuwaniu plików).
Idźmy dalej, to /etc/init.d/named namówił mnie na emerge --config. Odnaleźć w nim można funkcję start(), a w niej taką zawartość:

91 start() {
92 ebegin "Starting ${CHROOT:+chrooted }named"
93
94 if [[ -n ${CHROOT} ]];
95 then
96 check_chroot || {
97 eerror "Your chroot dir ${CHROOT} is inconsistent, please run 'emerge --config net-dns/bind' first"
98 return 1
99 }
100 einfo "Mounting chroot dirs"
101 _mount /etc/bind ${CHROOT}/etc/bind -o bind
102 _mount /var/bind ${CHROOT}/var/bind -o bind
103 _mount /var/log/named ${CHROOT}/var/log/named -o bind
104 fi
[...]
113 }

O! Jakieś mount -o bind (działania funkcji _mount() można się domyśleć). Więc zatrzymanie usługi wywoła _umount() i jest nadzieja, że znajdą się pliki!

Ufff! Udało się. Od teraz będę wykonywał kopie ważnych plików konfiguracyjnych, jeśli nie całego serwera. Przynajmniej do końca miesiąca.

Czemu przytrafiło mi się to teraz? Jak było wcześniej?
W /usr/portage/net-dns/bind/bind-9.4.3_p5.ebuild mamy:

243 pkg_config() {
244 CHROOT=`sed -n 's/^[[:blank:]]\?CHROOT="\([^"]\+\)"/\1/p' /etc/conf.d/named 2>/dev/null`
245 EXISTS="no"
246
247 if [ -z "${CHROOT}" -a ! -d "/chroot/dns" ]; then
248 CHROOT="/chroot/dns"
249 elif [ -d ${CHROOT} ]; then
250 eerror; eerror "${CHROOT:-/chroot/dns} already exists. Quitting."; eerror; EXISTS="yes"
251 fi
252
253 if [ ! "$EXISTS" = yes ]; then
254 einfo ; einfon "Setting up the chroot directory..."
255 mkdir -m 700 -p ${CHROOT}
256 mkdir -p ${CHROOT}/{dev,etc,var/run/named}
257 chown -R named:named ${CHROOT}/var/run/named
258 cp -R /etc/bind ${CHROOT}/etc/
259 cp /etc/localtime ${CHROOT}/etc/localtime
260 chown named:named ${CHROOT}/etc/bind/rndc.key
261 cp -R /var/bind ${CHROOT}/var/
262 chown -R named:named ${CHROOT}/var/

Czyli oprócz mkdir -p było również cp -R. Zmieniło się począwszy od wersji 9.4.3_p5-r1, ale wcześniej był jeszcze rozszerzony komunikat:

291 ewarn "NOTE: As of net-dns/bind-9.4.3_p5-r1 the chroot part of the init-script got some major changes!"
292 ewarn "To enable the old behaviour (without using mount) uncomment the"
293 ewarn "CHROOT_NOMOUNT option in your /etc/conf.d/named config."


Uczcie się na moich błędach i pokażcie mi swoje. Dojdziemy do doskonałości.

Bez bicia się przyznam, że nie zauważyłem tego wcześniej, a dowiedziałem się przy okazji próby aktualizacji dev-java/sun-jdk. Paczki, która nawet jest wymieniona w wiki od początku istnienia artykułu. Wymaga zaakceptowania licencji dlj (Operating System Distributor License for Java). W przeciwnym wypadku spotkamy się z komunikatem:

!!! All ebuilds that could satisfy "dev-java/sun-jdk" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-java/sun-jdk-1.6.0.18-r1 (masked by: dlj-1.1 license(s))
A copy of the 'dlj-1.1' license is located at '/usr/portage/licenses/dlj-1.1'.


No to czytamy, akceptujemy i instalujemy!

Odpowiedni parametr do mke2fs to -i <bytes-per-inode>.

Wybór sprzętu – coś małego, prostego do zainstalowania, z wyjściem VGA (początkowo wymogiem było TV-Out, ale po porównaniu z VGA w 1024 x 768, które większość telewizorów LCD obsługują, odpadło). Pierwszą testowaną płytą była Via Epia (nie pamiętam dokładnego modelu, prawdopodobnie seria LN, prywatnie mam słabszy model z serii M) z obudową Emko EM-151. Okazało się jednakże, że dopuszczalnym rozmiarem jest również obudowa Shuttle SS51G z płytą FS51, sprowadzane jako sprzęt z odzysku za niższą kwotę niż pierwszy zestaw.

Pierwsze zestawy miały dyski PATA i SATA, kolejne – karty CF z odpowiednimi adapterami PATA (lub SATA). Był też pomysł wstawiania pamięci flash na USB.

Wybór systemu prosty – GNU/Linux, a dokładnie Gentoo Linux. Konfiguracja sieci typowo jak w Gentoo + sekcja fallback, gdyby serwer DHCP nie był dostępny.

Uznałem, że najprościej (i najtaniej) efekt końcowy uzyskam wykorzystując przeglądarkę, można wsadzić dowolny format pliku i zawsze się jakoś wyświetli. Nie jestem grafikiem, więc samą animację robiła osoba trzecia. Ponieważ projekt miał ‘cieszyć oko’, więc został zrobiony we flash’u, a wyświetlany na Mozilla Firefox (Opera nie radziła sobie z tą animacją – zbyt ‘świeży’ flash).
Żeby przeglądarka mogła pracować, wymagała odpowiedniego środowiska. Wybrałem Xfce (na X.Org), bo samo X.Org nie dawało mi tylu możliwości (uruchamianie programów po starcie, zarządzanie zasilaniem). Urządzenie jest bezobsługowe, tzn. włącza się i wyłącza jednym przyciskiem. Automatyczne logowanie daje nam mingetty, a wyłączanie za pomocą acpid. Tutaj można znaleźć więcej informacji:

• Kilka sztuczek pod XFCE4.4

• Autologin – Hadret’s Blog

Zaskakujący dla mnie był fakt, że X.Org musi pracować z myszką (tzn. z widocznym wskaźnikiem). Nie da się go ukryć, wyłączyć, itp. Na szczęście jest unclutter, który wyłącza nieaktywny kursor (idle ustawiony na jedną sekundę).

Założenia wstępne były takie, by obraz wyświetlany był w pionie (czyli de facto 768 x 1024), za co odpowiada opcja:

Rotate „CCW”

w xorg.conf w sekcji Device dla karty graficznej. Sterowniku dla obu wspomnianych płyt obsługują to (odpowiednio via i sis).

Wspomniany Firefox pracuje z dodatkiem R-Kiosk (przy okazji: Opera i MS IE kiosk mode ma w standardzie), a w ustawieniach wyłączone zostało zapisywanie i pytanie o przywracanie sesji (odpowiednio browser.sessionstore.enabled i browser.sessionstore.resume_from_crash). Stosowny opis na stronach Mozilla:

• Session Restore – MozillaZine Knowledge Base

Treść do wyświetlania serwuje nginx (wraz z PHP jako FastCGI, dane z MySQL).

Działające zestawy można pooglądać w kantorach spółki Exchange Group (na pewno w Katowicach na ulicy Stawowej), a w przyszłości może też w miejscu, gdzie obecnie pracuję.

TODO:

• splashscreen przy uruchamianiu systemu,
• optymalizacja systemu (odchudzanie),
• być może w przyszłości coś, co pozwoli na rozstanie się ze środowiskiem X.

• Przy wielu adresach IP przypisanych do jednego interfejsu występuje problem przy starcie Xen.

Środowisko:

• sys-kernel/xen-sources-2.6.18-r12
• app-emulation/xen-3.3.0
• app-emulation/xen-tools-3.3.0

Dzieje się tak prawdopodobnie dlatego, że skrypt network-bridge (z /etc/xen/scripts; #!/bin/bash) w funkcji get_ip_info() pobiera adres do zmiennej addr_pfx za pomocą następującego zestawu poleceń (linia 104):

ip addr show dev $1 | egrep '^ *inet' | sed -e 's/ *inet //' -e "s/$1//"

co z kolei jest wykorzystywane w funkcji do_ifup() (linia 113):

ip addr add ${addr_pfx} dev $1

Na systemie z wieloma adresami (> 1) addr_pfx może wyglądać np. tak:

192.168.1.152/24 brd 192.168.1.255 scope global
192.168.160.153/24 brd 192.168.160.255 scope global

Przy do_ifup() pojawi się błąd:

Error: either „local” is duplicate, or „192.168.160.153/24″ is a garbage.

Podobny błąd był zgłoszony przez shadow(at)overdrawn(dot)net 16 stycznia 2008 r., ale dotychczas oficjalnie nic nie zostało z tym zrobione (Peter Große wyraźnie wskazuje na błąd skryptu i proponuje własną łatę na to).