Skip to content

Zgubna siła przyzwyczajeń

  • Zapamiętać – jak się robi pod Solarisem tar cf archiwum.tar /etc, to jeśli chcemy sobie to archiwum rozpakować po skopiowaniu na innego Solarisa, nie robić tar xf archiwum.tar. W przeciwieństwie do GNU tar, ten nie usuwa sobie ze ścieżki z archiwum przy rozpakowywaniu pierwszego ‘/’, co skutkuje nam nadpisaniem całego /etc…
    Pal diabli, jeśli zrobimy to na maszynie o tej samej architekturze – jeśli jednak na przykład /etc SPARC-owe rozpakujemy na maszynie x86, to dobrze byłoby pamiętać, że w /etc są też binarki – ostatnio zapomnienie i problem ze skojarzeniem tego faktu kosztował mnie stracone 4 godziny… ;)
  • Linuksowcy siadający do Solarisa: Zapomnijcie o killall tak chętnie używanym pod Linuksem, pod Solarisem robi trochę co innego – w zasadzie nazwa polecenia dokładnie odzwierciedla to, co robi. :) Za to nauczcie się korzystać z pkill. ;)

I zapewne cała masa innych rzeczy, chociaż te dwa najbardziej mnie (i chyba nie tylko) swego czasu zabolały…

OpenSolaris Developer Preview

Jak już zapewne każdy wie, w końcu się pokazał. Przez wielu oczekiwany, budzący wielkie nadzieje na coś nowego, inni patrzyli na niego sceptycznie, a jeszcze dla innych budzący całą falę dyskusji, kłótni…

Mowa o najnowszym dziecku projektu Indiana społeczności OpenSolaris: OpenSolaris Developer Preview. Czyli ISO płytki, która jest jednocześnie LiveCD pozwalającym zapoznać się z systemem, jak i go zainstalować – ostatnio chyba taka moda, żeby wszystko tak robić, swoją drogą nawet niegłupia. Ściągnąłem, odpaliłem w VMWare Server, relacja z tego poniżej.

Na wstępie uwaga – jeśli zamierzasz uruchamiać LiveCD pod VMware, może być konieczne ręczne poprawienie pliku z konfiguracją wirtualnej maszyny (*.vmx) – przynajmniej u mnie trzeba było dodać następującą linijkę:

Ethernet0.virtualDev = "e1000"

Bez tego nie miałem po prostu sieci.
Zatem zaczynamy – “wkładamy” płytkę, bootujemy z niej i naszym oczom ukazuje się jakże piękny i przecudowny GRUB w cudownych kolorkach, ze wspaniałymi gradientami… Pomijając kolor, to jakby w ogóle trochę znajomy, nie? ;)
GRUB LiveCD
Klikamy Enter, chwilę czekamy… Swoją drogą miło, że obraz oparto o najnowszy dostępny w tym momencie build – 75… Aż dochodzimy do pytania o układ klawiatury. Szczerze powiedziawszy to chyba już na zapas, bo w tym wydaniu nie zauważyłem, żeby wybranie polskiej klawiatury coś mi pomogło.
Pytanie o klawiaturę
W każdym razie wybieramy język, wciskamy Enter, chwilę czekamy… I zaskakująco szybko dostajemy iksy, uruchamia nam się Gnome i możemy próbować pracować.
LiveCD w pełnej krasie
Całość działa nawet przyjemnie – za dużo nie ma, ale to co jest, to po prostu funkcjonuje zgodnie z oczekiwaniami. Poza instalatorem, który jest w fazie pre-pre-pre-alpha i zapewnia naprawdę podstawową funkcjonalność. O czym zresztą sam nawet ostrzega. Ale jednocześnie to, co ma robić, robi z powodzeniem.
Instalator - krok 2
Instalacja pod VMWare trochę trwała, powiodła się sukcesem – system nawet się uruchomił bez problemów. Co mi się rzuciło na pierwszy rzut oka? A to, że rootfs jest pod ZFS-em – miłe.
System w działaniu
Drugie: mniej lub bardziej wyczekiwany obiecany pkg – czyli nowy system pakietów. Na pierwszy rzut oka wygląda obiecująco – chociaż jest trochę inny od wszystkiego, co do tej pory znałem. I może właśnie w tym nadzieja?
Mam wrażenie, że niezbyt podoba mi się wykorzystywanie FMRI do identyfikowania pakietów. Z drugiej strony widzę (a przynajmniej tak sądzę), że jednak w skuteczny sposób rozwiązuje i upraszcza zarządzanie repozytoriami, wersjami, buildami i aktualizacjami pakietów. Dokumentacja jest ciągle jeszcze dziurawa, ale widać, że położono nacisk na maksymalną elastyczność tego rozwiązania. I mam nadzieję, że się sprawdzi. :)

A oto galeria ze screenshotami z uruchomienia i instalacji:

PS. Niniejszy wpis sponsoruje potrzeba przetestowania jakiejś galerii w WordPressie (padło na NextGen) – stąd tak dużo obrazków, a tak mało sensownej treści. Obiecuję poprawę… kiedyś.

vim, UTF-8, ISO-8859-2 i lenistwo w czytaniu dokumentacji

Post bardziej sobie ku pamięci, ale może i komuś się przyda.
Problem: terminal UTF-owy, locale UTF-owe, plik w ISO-8859-2 (i w takim formacie ma pozostać). Standardowa próba otworzenia pliku kończy się krzaczkami. Próba zmian zmiennych “encoding”, “fileencoding”, “termencoding” przy już wczytanym dokumencie zakończyła się fiaskiem (i słusznie, dokumentację trzeba czytać, a nie kombinować na ślepo!)
Możliwe rozwiązania problemu:

  • ustawić sobie przed uruchomieniem vima odpowiednio zmienną “fileencodings” w ~/.vimrc – vim potrafi automagicznie rozpoznawać kodowanie pliku (pod uwagę bierze właśnie te wymienione w tej zmiennej) i wczytać go już prawidłowo odstawiając swoje magiczne sztuczki;
  • jeśli jednak już mamy otworzony dokument, to wymusić ponowne przeczytanie pliku wymuszając odpowiednie kodowanie: :e ++enc=iso-8859-2

Dziękuję za uwagę, dobranoc.

ZFS dla normalnych użytkowników

Czasami zachodzi potrzeba udostępnienia ogólnie pojętego zarządzania systemami plików na ZFS-ie zwykłym użytkownikom. Do tej pory istniała tylko możliwość poprzez dopisanie użytkownikowi odpowiedniego profilu (“ZFS File System Management” do zarządzania systemami plików, “ZFS Storage Management” do zarządzania pulami) i uruchamianie polecenia zfs w odpowiednim profilu (poprzez pfexec). Rozwiązanie to ma jednak jedną zasadniczą wadę – dotyczy wszystkich systemów plików ZFS bez możliwości ograniczenia praw użytkownikowi do np. jednego.

Z pomocą przychodzi “ZFS Delegated Administration”, które pojawiło się w OpenSolarisie, build 69 (pełna integracja, w tym poprawiony manual, jest dopiero w buildzie kolejnym). Co to daje? Spróbuję wyjaśnić na przykładzie:

Załóżmy, że mamy następującą pulę:

# zfs list
NAME    USED  AVAIL  REFER  MOUNTPOINT
zpool   121K  66,9G    19K  /zpool
#

Chcemy stworzyć system plików zpool/pandora, w którym użytkownik dosiu będzie mógł tworzyć i montować nowe filesystemy. Do tego stworzymy również zpool/hydra, gdzie użytkownik ada będzie w stanie tworzyć snapshoty oraz robić ich rollback.
Zatem tworzymy filesystemy:

# zfs create zpool/pandora
# zfs create zpool/hydra
#

Niestety możliwość montowania systemu plików wymaga odpowiednich uprawnień do katalogu – ustawmy więc dla uproszczenia przykładu po prostu sticky bit (uprawnienia do robienia snapshotów i rollbacku także wymagają uprawnienia do montowania filesystemu):

# chmod 1777 /zpool/{pandora,hydra}
#

I wydelegujmy odpowiednie uprawnienia:

# zfs allow dosiu create,mount zpool/pandora
# zfs allow ada snapshot,rollback,mount zpool/hydra
#

Sprawdźmy, czy wszystko działa zgodnie z naszymi oczekiwaniami:

dosiu@zfs2.dev:~ $ id
uid=100(dosiu) gid=1(other)
dosiu@zfs2.dev:~ $ /usr/sbin/zfs list
NAME            USED  AVAIL  REFER  MOUNTPOINT
zpool           188K  66,9G    21K  /zpool
zpool/hydra      18K  66,9G    18K  /zpool/hydra
zpool/pandora    18K  66,9G    18K  /zpool/pandora
dosiu@zfs2.dev:~ $ /usr/sbin/zfs create zpool/pandora/box
dosiu@zfs2.dev:~ $ /usr/sbin/zfs create zpool/pandora/medusa
dosiu@zfs2.dev:~ $ /usr/sbin/zfs destroy zpool/pandora/medusa
cannot destroy 'zpool/pandora/medusa': permission denied
dosiu@zfs2.dev:~ $ /usr/sbin/zfs create zpool/hydra/pegasus
cannot create 'zpool/hydra/pegasus': permission denied
dosiu@zfs2.dev:~ $ /usr/sbin/zfs snapshot zpool/pandora/box@today
cannot create snapshot 'zpool/pandora/box@today': permission denied

Czyli dla użytkownika dosiu wszystko jest, jak określiliśmy – ma prawo tworzenia (i montowania) nowych filesystemów w określonej lokalizacji, ale już nie może ich usuwać, czy też tworzyć snapshotów.

ada@zfs2.dev:~ $ id
uid=101(ada) gid=1(other)
ada@zfs2.dev:~ $ /usr/sbin/zfs create zpool/hydra/head
cannot create 'zpool/hydra/head': permission denied
ada@zfs2.dev:~ $ /usr/sbin/zfs snapshot zpool/hydra@today
ada@zfs2.dev:~ $ touch /zpool/hydra/test_file
ada@zfs2.dev:~ $ /usr/sbin/zfs rollback zpool/hydra@today
ada@zfs2.dev:~ $ /usr/sbin/zfs destroy zpool/hydra@today
cannot destroy 'zpool/hydra@today': permission denied
ada@zfs2.dev:~ $ /usr/sbin/zfs list
NAME                   USED  AVAIL  REFER  MOUNTPOINT
zpool                  242K  66,9G    21K  /zpool
zpool/hydra             18K  66,9G    18K  /zpool/hydra
zpool/hydra@today         0      -    18K  -
zpool/pandora           57K  66,9G    21K  /zpool/pandora
zpool/pandora/box       18K  66,9G    18K  /zpool/pandora/box
zpool/pandora/medusa    18K  66,9G    18K  /zpool/pandora/medusa
ada@zfs2.dev:~ $

I dla użytkownika ada też działa jak potrzeba – może tworzyć snapshoty, robić rollback, ale już na przykład nie jest w stanie wykonać destroy.

Wyświetlanie wydelegowanych uprawnień możliwe jest przez “zfs allow <nazwa/datasetu>, Na przykład:

# zfs allow zpool/hydra
-------------------------------------------------------------
Local+Descendent permissions on (zpool/hydra)
        user ada mount,rollback,snapshot
-------------------------------------------------------------

Składnia polecenia jest bardzo bogata (przy zachowaniu jej spójności) – pozwala ustawiać przywileje lokalnie i/lub dla potomnych datasetów w bardzo szerokim zakresie – więcej informacji znajduje się w manualu zfs(1) oraz na blogu Marka Shellenbauma.

Konwersja DocBook 5 do bardziej strawnych formatów

Jakiś czas temu leaderzy projektu opensolaris-pl podjęli decyzję o wzięciu się za tłumaczenie uwolnionych książek Suna. Na pierwszy ogień poszedł Solaris ZFS Administration Guide. Prace nad tłumaczeniem ZFSADMIN powoli posuwają się naprzód, niedługo prawdopodobnie będzie potrzeba przerabiania tych “nieszczęsnych” plików XML (Sun opublikował swoje książki w formacie DocBook 5 XML) do bardziej czytelnej formy dla przeciętnego użytkownika. Po straceniu całego dnia na zrozumienie, jak to właściwie działa, wkurzaniu się, czemu nie działa tak, jakbym ja sobie wymarzył, przeczytaniu prawie całego DocBook XSL: The Complete Guide (swoją drogą polecam – świetna książka) jestem gotów zaprezentować sposób przygotowania sobie środowiska do generowania ebooków w postaci HTML i PDF.

Uwagi:

  1. Jeśli chodzi o system operacyjny, opis bazuje na przykładzie Debian Unstable – akurat tego środowiska używałem w danym momencie;
  2. Poniżej podaję przykładowe konfiguracje programów, które działają u mnie – nie gwarantuję, że zadziałają też u Ciebie ;)
  3. Jeśli dostrzegłeś jakieś błędy, napisałem coś błędnie, chcesz dostarczyć informacji, jak to wygląda pod innym systemem – Jestem otwarty na krytykę

Co potrzebujemy?

W zależności od potrzeb:

  1. Obowiązkowo musimy posiadać (wystarczy to do konwersji dokumentów na HTML, XHTML, XSL-FO – ten ostatni jest etapem przejściowym do konwersji na PDF):
  2. Jeśli zależy nam na konwersji do formatu PDF, to oprócz tego musimy jeszcze doinstalować:
    • Procesor do konwersji XSL-FO na PDF – w naszym przypadku darmowy fop, większość takich procesorów jest komercyjna;
    • Biblioteka dla fop zawierająca reguły informujące o sposobie podziału wyrazów na sylaby (fop-hyph) do ściągnięcia tutaj (wersja stable);
    • Czcionki z polskimi znakami – domyślnie FOP korzysta z zestawu bazowych 14 czcionek Adobe (Helvetica, Times, Courier, każdy w wersji Normal, Italic, Bold, Bold Italic, oraz jeszcze czcionki Symbol i ZapfDingbats). Niestety czcionki te nie mają polskich znaków, więc w naszym przypadku musimy załączyć odpowiednie fonty bezpośrednio do PDF-a. Osobiście wykorzystałem czcionki TrueType Microsoftu: Verdana, Times New Roman, Courier New.

W większości dystrybucji elementy te są dostępne w paczkach z określonymi zależnościami. W Debianie sprowadza się to do:

# apt-get install xsltproc fop msttcorefonts

W repozytorium znajduje się także wersja arkuszy stylów DocBook (pakiet docbook-xsl), ale jest to wersja bez przestrzeni nazw (namespace). W związku z tym ściągamy tę wersję bezpośrednio z podanej wyżej strony (ostatnia wersja: docbook-xsl-ns-1.73.0) i rozpakowujemy w wygodnym nam miejscu (w moim przypadku /opt/share/xml/docbook/).

Wróćmy jeszcze do konfiguracji FOP. Domyślnie jest on wywoływany przez skrypt-wrapper /usr/bin/fop, który ma mały błąd – usiłuje traktować konfigurację jako skrypt shellowy – proponuję nałożenie tego patcha
Jeśli zamierzamy korzystać z biblioteki fop-hyph.jar, trzeba wskazać programowi jej lokalizację. Robimy to przez ustawienie zmiennej FOP_HYPHENATION_PATH.
Ponieważ będziemy potrzebować czcionki z polskimi literami, musimy wygenerować sobie tzw. metryki tych czcionek, po czym wskazać w konfiguracji fopa, pod jakimi nazwami będą one widoczne. Jako, że nie bardzo mamy ochotę zmieniać rodziny czcionek w całej dokumentacji Suna, zdecydowałem się na podmianę domyślnych fontów klasy serif, sans-serif i monospace odpowiednio na Times New Roman, Verdana i Courier New. Metryki umieściłem w katalogu /etc/fop/, generuje się je z plików TTF w następujący sposób:

# fop-ttfreader /usr/share/fonts/truetype/msttcorefonts/times.ttf /etc/fop/serif.xml

Analogicznie trzeba wygenerować metryki dla pozostałych czcionek i ich wersji (italic, bold, bold italic).
Następnie potrzebujemy jeszcze konfiguracji fopa z uwzględnieniem czcionek – przykładowa, prawie minimalna zawartość pliku /etc/fop.conf:

<?xml version="1.0"?>
<fop version="1.0">
  <base>.</base>
  <source-resolution>72</source-resolution>
  <target-resolution>72</target-resolution>
  <default-page-settings height="297mm" width="210mm"/>
  <renderers>

    <renderer mime="application/pdf">
      <filterList>
        <value>flate</value>
      </filterList>
      <fonts>
        <font metrics-url="/etc/fop/sans-serif.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/verdana.ttf">
          <font-triplet name="sans-serif" style="normal" weight="normal"/>
        </font>
        <font metrics-url="/etc/fop/sans-serifi.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/verdanai.ttf">
          <font-triplet name="sans-serif" style="italic" weight="normal"/>
        </font>
        <font metrics-url="/etc/fop/sans-serifb.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/verdanab.ttf">
          <font-triplet name="sans-serif" style="normal" weight="bold"/>
        </font>
        <font metrics-url="/etc/fop/sans-serifbi.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/verdanaz.ttf">
          <font-triplet name="sans-serif" style="italic" weight="bold"/>
        </font>

        <font metrics-url="/etc/fop/serif.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/times.ttf">
          <font-triplet name="serif" style="normal" weight="normal"/>
        </font>
        <font metrics-url="/etc/fop/serifi.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/timesi.ttf">
          <font-triplet name="serif" style="italic" weight="normal"/>
        </font>
        <font metrics-url="/etc/fop/serifb.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/timesbd.ttf">
          <font-triplet name="serif" style="normal" weight="bold"/>
        </font>
        <font metrics-url="/etc/fop/serifbi.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/timesbi.ttf">
          <font-triplet name="serif" style="italic" weight="bold"/>
        </font>

        <font metrics-url="/etc/fop/monospace.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/cour.ttf">
          <font-triplet name="monospace" style="normal" weight="normal"/>
        </font>
        <font metrics-url="/etc/fop/monospacei.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/couri.ttf">
          <font-triplet name="monospace" style="italic" weight="normal"/>
        </font>
        <font metrics-url="/etc/fop/monospaceb.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/courbd.ttf">
          <font-triplet name="monospace" style="normal" weight="bold"/>
        </font>
        <font metrics-url="/etc/fop/monospacebi.xml" kerning="yes" embed-url="/usr/share/fonts/truetype/msttcorefonts/courbi.ttf">
          <font-triplet name="monospace" style="italic" weight="bold"/>
        </font>

      </fonts>
    </renderer>

    <renderer mime="application/postscript">
    </renderer>

    <renderer mime="application/vnd.hp-PCL">
    </renderer>

    <renderer mime="image/svg+xml">
      <format type="paginated"/>
      <link value="true"/>
      <strokeText value="false"/>
    </renderer>

    <renderer mime="application/awt">
    </renderer>

    <renderer mime="image/png">
    </renderer>

    <renderer mime="image/tiff">
    </renderer>

    <renderer mime="text/xml">
    </renderer>

    <renderer mime="text/plain">
      <pageSize columns="80"/>
    </renderer>
  </renderers>
</fop>

Taka konfiguracja programu fop powinna nam zapewnić poprawne generowanie plików PDF z polskimi znakami.

Jak uzyskać z tego teraz książkę w formacie HTML?

Konwersja składa się z kilku etapów. Na początku dla każdej docbooka trzeba zbudować bazę odnośników, którą procesor później wykorzystuje do tworzenia prawidłowych linków pomiędzy w książce. Proces ten jest konieczny z racji rozbicia książki na pojedyncze pliki XML, w związku z czym procesor musi najpierw sobie stworzyć bazę, w którym pliku jakie identyfikatory odnośników występują. Robimy to wchodząc do katalogu książki i wydając polecenie:

$ xsltproc --xinclude \\
          --stringparam collect.xref.targets "only" \\
          /opt/share/xml/docbook/docbook-xsl-ns-1.73.0/html/chunk.xsl \\
          ZFSADMIN.xml

Wyjaśnienie parametrów:

  1. --xinclude – wymusza przetwarzanie dokumentów z użyciem specyfikacji XInclude. Cała dokumentacja Suna korzysta z tego rozszerzenia;
  2. --stringparam collect.xref.targets “only”stringparam w ogólności służy do przekazywania parametrów do arkuszy stylów – parametr collect.xref.targets odpowiedzialny jest za zachowanie przy natrafieniu na linki. Argument only określa, że chcemy tylko zebrać informację o linkach;
  3. /opt/share/xml/docbook/docbook-xsl-ns-1.73.0/html/chunk.xsl – ścieżka do arkusza stylów – wykorzystujemy chunk.xsl, żeby wygenerować dokumentację w formie kilkunastu podzielonych sensownie plików HTML (na przykład każdy rozdział w osobnym pliku HTML), zamiast jednego dużego (który uzyskamy po zastosowaniu docbook.xsl);
  4. ZFSADMIN.xml – ścieżka do “początku” dokumentu;

W wyniku działania powyższego polecenia uzyskamy plik target.db.

Następnie musimy posiadać plik XML opisujący listę “celów” powiązanych z bazą odnośników. W przypadku pojedynczej książki przykładowy plik wygląda tak (zapisałem go pod nazwą olinkbase.xml):

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE targetset
       SYSTEM "file:///opt/share/xml/docbook/docbook-xsl-ns-1.73.0/common/targetdatabase.dtd" [
<!ENTITY zfsadmintarget SYSTEM "file:///home/dosiu/docbook/ZFSADMIN/target.db">
]>
<targetset>
 <sitemap>
  <dir name="html">
   <document targetdoc="ZFSADMIN">
    &zfsadmintarget;
   </document>
  </dir>
 </sitemap>
</targetset>

Składnia pliku dość dobrze jest opisana w DocBook XSL: The Complete Guide (konkretnie tutaj), więc nie będę się dublować.
Mając to, możemy spróbować wygenerować plik HTML:

$ xsltproc --xinclude \\
          --stringparam chunker.output.doctype-public "-//W3C//DTD HTML 4.01 Transitional//EN" \\
          --stringparam chunker.output.doctype-system "http://www.w3.org/TR/html4/loose.dtd" \\
          --stringparam chunker.output.encoding UTF-8 \\
          --stringparam target.database.document "olinkbase.xml" \\
          --stringparam current.docid "ZFSADMIN" \\
          -o html/index.html \\
          /opt/share/xml/docbook/docbook-xsl-ns-1.73.0/html/chunk.xsl \\
          ZFSADMIN.xml

Z przekazywanych parametrów dość ważne jest chunker.output.encoding – domyślnie pliki HTML generowane są z użyciem kodowania ISO-8859-1. Podanie tego parametru wymusza użycie wskazanego kodowania. chunker.output.doctype-public oraz chunker.output.doctype-system nie są konieczne, ale zapewniają poprawną składnię plików HTML dla wszelakich parserów. target.database.document przyjmuje jako argument ścieżkę do pliku XML, gdzie opisywaliśmy strukturę katalogów z książkami. Z kolei parametr current.docid mówi procesorowi, jaki identyfikator nosi konkretnie parsowana przez nas książka – identyfikator ten musi być zgodny z tym, jaki podaliśmy w podanym wcześniej pliku XML.

W wyniku (prawdopodobnie po kilku ostrzeżeniach związanych z niepoprawnym rozwiązaniem linków do innych dokumentacji, na przykład manuali) powinniśmy otrzymać w katalogu html/ kilkanaście gotowych plików HTML.

Domyślnie generowany HTML jest dość prosty, jeśli chcemy go “upiększyć”, warto użyć parametru html.stylesheet przyjmujący jako argument ścieżkę do pliku CSS.

A jeśli chcemy PDF?

Konwersja do PDF jest dwuetapowa – najpierw konwertujemy z DocBook do formatu XSL-FO, który jest dopiero podstawą do wygenerowania PDF.

Początkowe kroki są wspólne – czyli również musimy wygenerować sobie bazę odnośników, stworzyć plik XML, który wiąże targetdoc z odpowiednią bazą. Używamy tylko innego arkusza stylów docbook – z podkatalogu fo/ (chociaż dla etapu generowania bazy nie ma to jeszcze znaczenia):

$ xsltproc --xinclude \\
          --stringparam collect.xref.targets "only" \\
          /opt/share/xml/docbook/docbook-xsl-ns-1.73.0/fo/docbook.xsl \\
          ZFSADMIN.xml

Następnie generujemy plik XSL-FO. Na tym etapie możemy określić formatowanie dokumentu – rodzaje podstawowych czcionek, rozmiar papieru (domyślnie letter), rozmiar czcionki – w moim przypadku wywołanie wygląda tak:

$ xsltproc --xinclude \\
          --stringparam paper.type A4 \\
          --stringparam body.font.master 8 \\
          --stringparam target.database.document "olinkbase.xml" \\
          --stringparam current.docid "ZFSADMIN" \\
          -o ZFSADMIN.fo \\
          /opt/share/xml/docbook/docbook-xsl-ns-1.73.0/fo/docbook.xsl \\
          ZFSADMIN.xml

Kolejny etap to już tylko konwersja do formatu PDF z użyciem FOP:

$ fop ZFSADMIN.fo -pdf ZFSADMIN.pdf

Wszelkie “warningi” występujące na tym etapie najczęściej związane są z tym, że elementy określone jako niepodzielne, nieprzenaszalne nie mieszczą się w wyznaczonym obszarze strony. Niestety fop niezbyt dobrze radzi sobie z takimi elementami i często w tych miejscach PDF może nam się trochę rozjechać. Jak sobie z tym poradzić? Poprawić książkę, poprawić fopa, użyć innego programu. ;)

Nudy część druga

Czyli inaczej mówiąc – drugi quasitutorial związany z projektem tłumaczenia portali i dokumentacji OpenSolaris. Z racji mojego środowiska pracy, tutorial jest zorientowany na środowiska *niksowe (Solaris/Linux), niestety nie jestem w stanie podać odpowiednich informacji, jak sobie zorganizować środowisko pracy pod Windowsem do tego celu. Jeśli ktoś chciałby się podzielić opisem lub jakimiś wskazówkami: zapraszam.

Te “kilka” słów poniżej zostało zainspirowanych odwiecznymi pytaniami, w jaki sposób uzyskać dostęp do repozytorium i jak posługiwać się SVN-em.

Po spełnieniu wszystkich warunków z jednego z poprzednich wpisów, powinniśmy dysponować kontem w strukturze developer.berlios.de, co jest równoznaczne z posiadaniem również “ograniczonego” konta SSH na shell.berlios.de. Powinniśmy być także dopisani do projektu opensolarispl. Od tego momentu uzyskujemy dostęp do repozytorium SVN projektu (jeśli brakuje Ci narzędzi, najwyższa pora doinstalować co trzeba – w większości przypadków odpowiedni pakiet nazywa się subversion).

Dla wygody użytkowania dobrze jest wygenerować sobie parę kluczy ssh (polecenie ssh-keygen) i umieścić klucz publiczny (wygenerowany domyślnie jest zapisywany w ~/.ssh/id_rsa.pub) w ~/.ssh/authorized_keys na serwerze – dzięki temu unikniemy potrzeby ciągłego wpisywania hasła (z SVN będziemy korzystać po SSH, wykonanie jakiegokolwiek update’u czy commita wymagałoby od nas trzykrotnego podawania tegoż – po co sobie utrudniać życie?).

Krótki tutorial używania SVN:

  • svn checkout svn+ssh://twój_login_na_berlios@svn.berlios.de/svnroot/repos/opensolarispl/trunk
    Po tym poleceniu udajemy się na kawę/herbatę/lody/spacer/do kina (w zależności od prędkości łącza – ściąga ono całe repozytorium na dysk, aktualnie jest to 184MB);
  • svn update (lub svn up – wiele poleceń svn ma swoje wersje skrótowe)
    Polecenia tego używamy w celu wyrównania naszej lokalnej kopii repozytorium z tą na serwerze – używamy go potem w zasadzie ciągle poza pierwszym inicjującym “checkout” – ściąga tylko różnice, dzięki czemu działa bardzo szybko;
  • svn [-m "opis zmian"] commit [opcjonalne nazwy plików]
    Polecenie to wysyła naszą wersję zmian do repozytorium. Sprawdza najpierw, jakie pliki zmienialiśmy, następnie (jeśli nie określiliśmy od razu tego przez -m “opis zmian”) uruchomi nasz ulubiony edytor tekstu celem napisania krótkiego komentarza o dokonanych przez nas zmianach w plikach, po czym sprawdzi, czy zatwierdzane przez nas pliki nie zostały w międzyczasie przez kogoś innego zmienione w repozytorium – w takim przypadku zostaniemy poproszeni odpowiednim komunikatem o ręczne rozwiązanie problemu. Jeśli natomiast wszystko się powiedzie, dostaniemy komunikat o nowej wersji repozytorium.

Z pierwszego polecenia korzysta się raz, na początku (i tylko przy nim trzeba podawać dokładną ścieżkę oraz nasz login do repozytorium) – w dalszej pracy używa się pozostałych dwóch poleceń. Polecam zapoznanie się z manualem i dokumentacją od subversion – narzędzie to potrafi dużo więcej. Z przydatnych opcji mamy też na przykład:

  • svn blame plik
    Polecenie to nam wyświetla plik przy każdej linii wyświetlając numer wersji, gdzie ostatnia została zmieniona i przez kogo.
  • svn cat plik[@wersja]
    Polecenie to po prostu wyświetla plik. W przypadku podanej wersji wyświetli nam, jak wyglądał on właśnie wtedy.

Powodzenia!

Tak, nudni jesteśmy. Wiemy.

Pewnie macie mnie i trocheja już dosyć, ale pomarudzę jeszcze (zakładając, że ktokolwiek to czyta). A co mi tam…

Praktycznie każda nowa osoba, która chce dołączyć do projektu tłumaczenia portalu i dokumentacji OpenSolaris zadaje wciąż pytania, co trzeba zrobić, żeby móc w tym uczestniczyć. Poniżej postaram się usystematyzować wszystkie niezbędne do tego celu kroki.

  • Przede wszystkim (i to jest najważniejsze) – trzeba mieć podpisany tzw. Sun Contributor Agreement (SCA) i przydzielony na jego podstawie Sun Contributor Number (SCN). Każdy, kto miał już jakikolwiek udział w projekcie OpenSolaris, wie o co chodzi, jeśli nie miał, to proponuję zapoznać się z SCA FAQ (po polsku). Formularz oraz dokładne informacje jak i gdzie go wysłać, znajdziesz tutaj (po angielsku).
  • Repozytorium naszego projektu jest utrzymywane w infrastrukturze BerliOS, w związku z tym potrzebujemy obowiązkowo konto na developer.berlios.de (w tej “gałęzi” znajdują się potrzebne nam repozytoria). W tym momencie dostajemy dostęp do konta WWW, gdzie możemy uzupełnić swój profil, przejrzeć do jakich projektów jesteśmy dodani, itp.
  • Po pozytywnym załatwieniu obu powyższych punktów, zgłaszamy się do jednego z liderów projektu z prośbą o dopisanie do projektu opensolaris-pl i swoim loginem na “berliosie”. Po uzyskaniu potwierdzenia wykonania tej operacji powinniśmy dostać na “berliosie” konto ssh – powinno być założone maksymalnie w ciągu jednego dnia, więc proszę być cierpliwym. W przypadku problemów proponuję zgłosić ten problem opiekunom developer.berlios.de – rzadko, ale czasem niestety się zdarzają.
  • Od tego momentu możemy pracować z repozytorium SVN (podstawowe informacje jak zacząć – tutaj).

I jeśli chodzi o podstawowe informacje – to wszystko. Uzgadniamy z liderami co chcemy robić i robimy.
Kontakt z nami jest możliwy przez listę dyskusyjną g11n-pl-discuss, na IRC-u w sieci FreeNode na kanale #opensolaris-pl lub forum forum.opensolaris.org.pl. Dopuszczony oczywiście również kontakt prywatny (adresy mailowe czy inne metody proszę sobie inteligentnie samemu znaleźć, nie będę dawał pożywki spambotom). Pomożemy na ile będziemy w stanie.

Uwaga: NIE robimy “samowolki” biorąc dowolny dokument i tłumacząc bądź poprawiając cokolwiek nam się podoba. Uzgadniamy podział zadań z liderami projektu. Aktualnie portal jest już przetłumaczony w podstawowej części i chwilowo przy nim nie ma za dużo pracy (głównie ciągle korekta), natomiast tłumaczymy również locale/manuale oraz uwolnione podręczniki. Jeśli interesuje Cię przydział, zgłoś się do trocheja (locale/manuale) lub do mnie (podręczniki).

Ciekawostki przyrodnicze

Stało i kurzyło się… Tak nie mogło być. W końcu zmobilizowałem się i uruchomiłem. Działa. Nawet stabilnie.

dosiu@easymint:/home/dosiu> uname -a
FreeMiNT easymint 1.15.12 4.4 falcon mc68060
dosiu@easymint:/home/dosiu> uptime
6:06pm up 17:53, 3 users, load average: 0.00, 0.02, 0.04
dosiu@easymint:/home/dosiu> free
268369920 bytes (262080K) free.
dosiu@easymint:/home/dosiu> cat /kern/cpuinfo
CPU: 68060
MMU: 68060
FPU: 68060
Clockspeed: 5 MHz
BogoMIPS: 10.19
dosiu@easymint:/home/dosiu> /sbin/ping wp.pl
PING wp.pl (212.77.100.101): 56 data bytes
64 bytes from 212.77.100.101: icmp_seq=0 ttl=119 time=60.000 ms
64 bytes from 212.77.100.101: icmp_seq=1 ttl=119 time=45.004 ms
^C
----wp.pl PING Statistics----
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 45.004/52.502/60.000/10.604 ms

Nie mam pojęcia, czemu przekłamuje prędkość procesora (w praktyce jest to 85MHz), być może to jakiś bug w użytym kernelu. Cała reszta się zgadza (sprzęt: Atari Falcon030 + CT63).
No i jeszcze nie bardzo mam pomysł, czemu świeżo skompilowane ekg nie chce mi się połączyć z żadnym serwerem – ale to też tylko kwestia czasu… Kiedyś działało.

A jaki szpan na dzielni… ;)

Rachunek sumienia

Co to z człowiekiem się porobiło… Wczoraj doszedłem do strasznego wniosku. Ja, swego czasu zawzięty linuksiarz, używający tego systemu od drugiej połowy lat 90-tych ubiegłego wieku, przez ponad 5 lat używający tego systemu jako jedynego słusznego zarówno na desktopie, jak i później na laptopie (nawet bez żadnego tzw. WUPW*), używam od jakiegoś czasu:

  1. Desktop:
    • 70% czasu: Windows XP
    • 30% czasu: Solaris Express
  2. Laptop:
    • 95% czasu: Windows XP
    • 5% czasu: Solaris Express**

Czasem na chwilę na którymś z nich stanie jakieś Ubuntu czy inne SuSE. Popatrzę, stwierdzę, że fajnie to się nawet rozwija i… wracam do Windowsa. Starzeję się?
Jedyny wyjątek: w pracy, z racji jej charakteru, siłą rzeczy mam Linuksa. Chociaż i tam zastanawiam się nad przesiadką na Solarisa… Za to nie ma Windowsa. ;)

* – WUPW == Wstydliwie Ukrywana Partycja Windowsowa
** – SX na laptopie ma jeszcze problemy z obsługą niektórych elementów… Ale idzie ku dobremu. :)

Fortunka?

Z dyskusji na temat ZFS-a i Linuksa na jednym z kanałów IRC-owych (nick ocenzurowano na prośbę dyskutanta):

/…/
194601 <@xx> pjd dał radę – dlaczego więc miałoby im to zająć jakoś w cholerę czasu? bo nawet gdyby powiedzmy 2x tyle pisali….. to ile by im wyszło?
194605 < trasz> xx: ‘not invented here’.
194611 < trasz> xx: piec lat?
194625 <@xx> a pjd w ile portował?
194632 < trasz> xx: pjd _portowal_.
194646 < trasz> xx: port by zajal pare miesiecy.
194651 <@xx> a oni nie mogę portować ze względów ideologicznych, tak?
194659 <@dosiu> Ta.
194701 <@xx> bo przepisywania to w ogóle bez sensu – na pewno popsują
194705 <@dosiu> :D
194708 < trasz> xx: nie tyle ideologicznych, ile z powodu… hm. zacietrzewienia.
194710 <@xx> i będzie gorsze niż ext

Motyw z popsuciem zdecydowanie mnie rozbawił…

A poza tym, żeby było coś bardziej rzeczowego: żeby nie było, że tylko pienię się i gadam bez sensu, dołączyłem się do projektu tłumaczenia portalu www.opensolaris.org na język polski. W związku z tym dołączam się do apelu trocheja – każda możliwa pomoc przy projekcie się przyda. Więcej szczegółów u niego na blogu.

I skoro jestem już przy apelach i linkowaniu innych: może ktoś chętny chciałby w jakikolwiek sposób pomóc zorganizować znajomemu nietypową wyprawę? Za każdą pomoc będzie dozgonnie wdzięczny.