Trzy kroki przed orkiestrą, czyli stary AfterShotPro(3) na nowej Fedorze(33)

    Trochę fotografuję, a że dość kiepsko, to muszę potem moje "dzieła" poprawiać. Tu doświetlić, tam kolor podkręcić, gdzieś coś z cienia wyciągnąć czy wykadrować jakiegoś przeoczonego "mistrza drugiego planu". Dość, by robić zdjęcia w surowym formacie NEF (RAWy z mojego ukochanego Nikona). Jestem też linuxowym talibem. Jeśli wychodzi nowe wydania Fedory, to zwykle je instaluję jeszcze tego samego dnia kiedy wyjdą. Pozwala mi to cieszyć się najnowszymi "ficzurami" ulubionej dystrybucji, ale dostarcza też sporo niespodzianek i rozrywki, zwłaszcza z zamkniętym oprogramowaniem, które często nie nadąża za open source. I tu dochodzimy do sedna: od dawna jestem (coraz mniej szczęśliwym) posiadaczem licencji komercyjnego, i oczywiście zamkniętego Corel AfterShotPro. Przesiadki na otwartego Darktable jakoś mi nie wyszły.

    Corel AfterShot Pro 3 to fajny, intuicyjny i ultraszybki  program do obróbki zdjęć w formacie RAW.  Dostawca niestety traktuje wersję linuxową jak drogowcy zimą drogę w mojej wsi: nie odświeżył wersji już od dwóch lat. A Fedora w międzyczasie poszła ostro do przodu. Jak wiadomo, ta dystrybucja potrafi zrobić grube zmiany w ABI pomiędzy wydaniami. W efekcie AfterShoot przestał działać już na wersji F32, nie wspominając o bieżącej F33. Oczywiście od czego KVM/VirtualBox/VMware? Ale po co utrzymywać CAŁĄ, około 30 GiB maszynę, żeby trzymać software wielkości 70MiB?  Dlatego zdecydowałem się na kontenery. 

    Mówiąc w skrócie, mój pomysł jest rozwinięciem koncepcji przedstawionej tutaj, i sprowadza się do:

• Stworzenia definicji obrazu kontenera.
• Zbudowania go
• Uruchomienia programu
• Posprzątania po zatrzymanym kontenerze. 

Dockerfile

    Natywnym dla Fedory (czyt. przyszłych Red Hatów) systemem obsługi kontenerów jest podman. Jest fajny, bo:

• jest daemonless - nie ma żadnego demona do obsługi kontenerów.
• domyślnie działa z konta zwykłego użyszkodnika a nie roota  - przy klasycznym Dockerze trzeba to trochę pokofigurować.
• Jest kompatybilny z Dokckerem więc przesiadka jest bezbolesna.

Trochę metodą prób i błędów, trochę przy pomocy zaprzyjaźnionego inkwizytora Dockerowo/Kubernetesowo/OpenShiftowego (Michał Stryga) doszedłem do takiego Dockerfile:

FROM fedora:31

ADD AfterShotPro3.rpm /AfterShotPro3.rpm

ADD start.sh /start.sh

RUN dnf -y install AfterShotPro3.rpm glx-utils xterm mesa-dri-drivers compat-openssl10 xorg-x11-fonts-Type1 xorg-x11-fonts-ISO8859-1-100dpi dejavu-sans-fonts dejavu-serif-fonts liberation-serif-fonts 

CMD ["/start.sh"]

    Jak widać, niezwykle prosty:

1. Korzysta z bazowej Fedory w wersji 31 - Wiem, wiem, niewspierana, ale właśnie ta musi być, bo to ostatnia na jakiej AfterShot 3 (A konkretnie 3.6.0.380) działa.
2. Dodaje do obrazu pakiet ze wspomnianym AfterShotem oraz skryptem startującym. - sekcje ADD.
3. Instaluje potrzebne pakiety. Teoretycznie sam AfterShot definiuje swoje zależności, więc dnf'owi powinien wystarczyć tylko ten pakiet, ale jak to w komercyjnych softach bywa, definiuje je niedbale. Stąd, metodą prób i błędów, okresliłem listę pakietów, które są mu potrzebne do szczęścia.
4. Jako "Entry Point" definiuje skrypt start.sh, którego zadaniem jest "zaczarowanie" OpenGL i GLXa. Znowu, metodą prób i błędów, okazało się, że binarka AfterShota nie startuje, jeśli ktoś przed nią nie wykona czegoś na GLXie, ot choćby wystartuje glxinfo. Zatem zawartość mojego skryptu wygląda tak:

#!/bin/bash

glxinfo

/usr/bin/AfterShot3X64

Budowanie obrazu kontenera

    Do zbudowania obrazu kontenera w Fedorze służy buildah:

$  buildah bud -t aftershoot:3

Po tej operacji komenda podman images powinna pokazać coś takiego:

$ podman images            

REPOSITORY            TAG     IMAGE ID      CREATED       SIZE

localhost/aftershoot  3       b4ba6c8f9b47  3 hours ago   1.09 GB

registry.fedoraproject.org/fedora  31      a7a37f74ff86  8 months ago  199 MB

Start kontenera

    Pora uruchomić kontener. Tu dzieje się kilka  mniej oczywistych  rzeczy, bo uruchamiam aplikację, która ma wyświetlać coś na ekranie i to na dodatek z dostępem do sieci hosta, lokalnego katalogu i przede wszystkim karty graficznej. Dlatego w zaklęciu potrzeba kilku parametrów:

$ podman  run --net host --privileged --env "DISPLAY" --volume "$HOME/.Xauthority:/root/.Xauthority:rw" --volume "/etc/machine-id:/etc/machine-id"  --volume "/home/marcinek/Obrazy:/root/Pictures" localhost/aftershoot:3

    Po kolei:

• net host - chcę, żeby kontener korzystał bezpośredni z sieci hosta.
• privileged - kontener ma mieć dostęp do sprzętu, np karty graficznej.
• en "DISPLAY" - przenieś zmienną $DISPLAY hosta do kontenera, żeby ten wiedział gdzie jest jego ekran X11.
• volume "$HOME/.Xauthority:/root/.Xauthority:rw" - udostępnij plik autoryzacji do ekranu X11.
• volume "/home/marcinek/Obrazy:/root/Pictures" - udostępnij mój katalog ze zdjęciami, żeby było na czym pracować :-)

Taaadaaam!

Sprzątanie po robocie

    Po skończonej robocie, kontener zostaje w stanie "exited". 

$ podman ps -a                                             

CONTAINER ID  IMAGE COMMAND    CREATED        STATUS                     PORTS   NAMES

98987600e9df  localhost/aftershoot:3  /start.sh  3 minutes ago  Exited (0) 16 seconds ago          kind_kowalevski

Sprząta się to tak:

$ podman container rm 98987600e9df                         

98987600e9dffa85521353d6be4b05081e7580afaed6063e39c18231edc260b1

P.S

    Zostało tu trochę miejsca na ulepszenia:

• Można by zakombinować, żeby użytkownik wewnątrz kontenera to nie był root.
• Wypadałoby podmapować jeszcze jakiś wolumen z licencją. W przeciwnym wypadku, każde uruchomienie programu uruchamia od nowa próbny okres licencyjny :-D 
• Pewnie jest jakiś prstryk-elektryk, żeby kontener automatycznie znikał, gdy aplikacja się zakończy.
• Mój laptop ma GPU a AfterShot potrafi korzystać z OpenCL, co jeszcze bardziej przyspieszy wołanie RAWów.