Instalacja GG pod Linuxa (Ubuntu 12.04 LTS PL)

[wrzomar]

Podlinkowanie, tak jak to robi Chrome, nie pomoże, bo skrypt gg ustawi GG_PATH w ten sposób, że nie znajdzie gghub. Napisanie skryptu podobnego do tego z archiwum z GG jest formą podlinkowania, tylko że bez symlinka. Fajnie jest rozwiązana sprawa aktualizacji JDK od Oracle (dawniej od Sun, zanim Oracle ich nie wykupiło). Zgodnie z licencją nie można dystrybuować ich oprogramowania na własną rękę, więc gdy Java zostaje zaktualizowana, WebUpd8 zamieszcza paczkę deb, która podczas konfiguracji ściąga archiwum ze strony Oracle i instaluje je w systemie.

PS. Dobrym przykładem na samo-aktualizację jest dropbox, który wypuścił pakiet deb instalujący skrypt, który służy do kontrolowania dropbox'a, a jeśli nie znajdzie zainstalowanego w katalogu użytkownika zamkniętego składnika, to ściąga go i instaluje, a dropbox aktualizuje się w tle podczas pracy. Skoro gg i tak musiałoby być uruchamiane ze skryptu, to może on robić coś więcej poza uruchamianiem, np. instalować jeśli zajdzie potrzeba i sprawdzać integralność oraz autentyczność GG.

[epsilon]

A moze by to zrobic tak.
Bylby sobie skrypt instalatora, ktory oferowalby na starcie 2 scenariusze:
1) instalacja do /opt/GG
skrypcik prosi o haslo roota, po czym
- zaklada w systemie nowe konto i nowa grupe np. gaduuser i gadugroup
- dorzuca do pliku sudoers (nie mam teraz glowy do szukania skladni) ze kazdy user moze wywolac komende /opt/GG/gghub (albo jakis plik co uruchamia updater)
na prawach gaduuser.gadugroup
- kopiuje pliki gg do /opt/GG i nadaje im wlasciciela na gaduuser.gadugroup rwx 775
- linkuje gg.desktop, ikonki, itp do odpowiednich miejsc + dodaje sie ewentualnie do PATH

2) instalacja do katalogu zwyklego usera np .local/GG
tutaj kopiuje pliki na prawach biezacego usera oczywiscie, do jego katalogu
i podlinkowuje tam gdzie trzeba gg.desktop, ikonki, itp do odpowiednich miejsc tylko dla tego usera
tutaj sprawa updatera jest rozwiazana jak teraz

3) pozostaje jeszcze trzecia opcja, sami sobie kopiujemy do lokalizacji jakiej chcemy
i ustawiamy takie prawa i wlasciciela jak chcemy, przed aktualzacja zmieniamy prawa
na takie zeby mogl sie zaktualizowac...

a teraz uruchomienie
zwykly user uruchamia plik-skrypt "gg", tak jak teraz
skrypt sprawdza czy "gghub" ma wlasciela gaduuser.gadugroup
1) jesli tak robi sudo (gaduuser.gadugroup) /opt/GG/gghub (skladni nie pamietam) robi ewentualnie sobie aktualizacje i sie wylacza
skrypt nastepnie uruchamia go jeszcze raz "gghub" juz na prawach zwyklego usera, czyli z mozliwoscia tylko uruchamiania i czytania, plikow z /opt/GG
2) jesli plik gghub nie ma wlasciciela gaduuser.gadugroup, to sprawdza czy uruchamiajacy "gg" jest wlascicielem pliku gghub
jesli tak to uruchamia sie tak jak teraz, ewentualnie sie aktualizuje
3) ostatnia opcja ze wlasciciel gghub i uruchamiajacy to inne konta, wtedy po uruchomieniu updatera jezeli sa aktualizacje to wyskakuje komunikat, ze
program nie zostal zaktualizowany, ze wzgledu na brak dostepu... i zakonczenie skryptu i gg.

pozostaje kwestia uruchamiania "gghub" tak zeby wiedzial czy to uruchomienie przed aktualizacja czy po aktualizacji,
moze przez parametr albo jakis dodatkowy plik, tworzony przed aktualizacja, a usuwany po lub jej braku...


To tylko taka jakby koncepcja, i nie jestem przekonany czy to sie da zaimplementowac na tej wersji co jest. W kazdym razie
nie chcialbym byc zmuszonym do instalacji gg za pomoca jakiegos deb'a czy rpm'a z poziomu root'a.
i wszystko zeby bylo w jednym miejscu, odinstalowywuje przez usuniecie...

Niestety ale o programowaniu mozna by rzec mam juz obecnie niewielkie pojecie, o webapp nie wspomne.
Zobaczymy zreszta jak bedzie wygladal plik z wersja linuxowa gg w nastepnym wydaniu, bo moze nasze rozwazania
nie sa warte swieczki...

PS. powyzsze pisane po piwie, wiec nie zamierzam bronic powyzszego jak Monte Cassino
wlasciwie to mnie sytuacja obecna odpowiada...

aha oczywiscie mozliwe ze gg dziala zupelnie inaczej z ta aktualizacja, niz mysle wiec cale moje rozwazania mozna potluc o kant d...

[wrzomar]

Ja to sobie wyobrażam ten skrypcik podobnie jak w Dropbox, tzn. jak najszybsze uruchomienie GG i ewentualnie instalacja, jeśli nie jest zainstalowany. Zanim uruchomi GG sprawdzałby czy istnieje /opt/GG/gghub, jeśli tak - to ustawia odpowiednio GG_PATH i uruchamia gghub, jeśli nie, to sprawdza czy istnieje $HOME/.local/GG/gghub i robi tak jak wyżej, jeśli nie to sprawdza czy istnieje zapisane wcześniej archiwum z GG (np. w /var/cache/gg-installer/) i jeśli tak to rozpakowuje je do $HOME/.local/, a jeśli nie istnieje to ściąga z netu i rozpakowuje. To tak z grubsza. Można zrobić dwie wersje, dla i386 i dla amd64, w celu uproszczenia samego skryptu, lub jedną, żeby w przyszłości powstała jedna paczka, a nie dwie. Byłbym za dwiema wersjami, bo będzie prostsze do napisania, a sam skrypt wymagałby bash, wget i tar. Instalowanie w /opt/GG można umieścić w innym skrypcie lub dołączyć do tamtego, np. jeśli ma odpowiednie uprawnienia do zapisu w /opt (tzn. był uruchomiony z sudo). Pozostaje kwestia konta gościa, nie wiem jak mógłby sprawdzić, że jest uruchomiony z konta gościa, ale załóżmy, że wyjście w whoami byłoby sprawdzane czy zawiera guest lub czy $HOME znajduje się w /tmp, skrypt musiałby rozpakować archiwum do $HOME/.local nawet jeśli istnieje /opt/GG/gghub. Poprawcie mnie jeśli się mylę, bo pisałem na szybko.

[Sweetashny Miszcz]

/var/cache? Jezusie... Co za konwencja to proponuje?!

[wrzomar]

Nie wzywaj Imienia Pana nadaremno Fajnie, że łapiesz mnie za słówka, naprawdę super z Twojej strony! Zaprawdę powiadam Tobie, że WebUpd8 Team umieszcza w nim (a dokładnie np. w "/var/cache/oracle-jdk7-installer/") ściągane archiwum z jdk i przechowuje je tam do następnej aktualizacji, żeby niepotrzebnie nie pobierać tego samego archiwum gdy wydadzą aktualizację samego instalatora.
Dla zwykłego użyszkodnika, który nie ma prawa używać sudo, a Jego Wysokość Admin nie zainstalował w /opt/GG dla wszystkich, instalator pobierałby i przechowywał (lub nie) archiwum gdzieś w katalogu tegoż użyszkodnika. Tylko, że kiedy ostatnio to sprawdzałem, GG Networks w linku do archiwum nie umieściło numeru wersji.
Linki wyglądają następująco:
- wersja 32-bit: http://im-updates.gg.pl/files/release/linux32
- wersja 64-bit: http://im-updates.gg.pl/files/release/linux64
więc wget zapisze archiwum jako linux32 lub linux64. Można mu podać opcję -O z odpowiednią nazwą pliku. Zaletą braku numeru wersji jest to, że nie trzeba będzie zmieniać linków, a pobrana zostanie zawsze najnowsza wersja. Wadą, że wersję GG można poznać dopiero po ściągnięciu archiwum, które do najmniejszych nie należy.
Sens trzymania gdzieś na dysku archiwum jest taki, żeby w razie potrzeby szybko rozpakować je bez ściągania z Internetu, a aktualizacja GG instalowanego dla wszystkich (w odróżnieniu od - dla pojedynczych użytkowników), a właściwie dbanie o to, żeby wersja zainstalowana była tą samą co aktualna, byłoby w odpowiedzialności admina. Z wielką władzą idzie wielka odpowiedzialność.

[Rafix]

Ok, ale wy piszecie ten instalator czy co? Bo ja się w tym pogubiłem....
Zrobienie prostego instalatora na wszystkie dystrybucje Linux w bashu+zenity (lub w zastępstwie w zwykłym terminalu) to żaden problem przecież, a sposobów jest więcej niż użytkowników. Użytkownika ma to gdzieś czy będzie to w /opt czy /usr/local czy katalogu użytkownika - przede wszystkim to się instalować na 2 kliknięcia i działać.

[wrzomar]

Kusi mnie, żeby to zrobić, ale nie wiem czy ulegnę tej pokusie. Tylko z tym prostym instalatorem na wszystkie dystrybucje będzie kiepsko, bo w tej chwili nie potrzeba instalatora,żeby rozpakować archiwum gdzie się chce. Nie wiem jak u innych, ale u mnie wszystko działało od razu (oprócz kamerki, która działa z wszystkimi programami prócz GG i Tlen.pl), a czytałem o kłopotach z flash'em itp. No i integracja z Unity jest dość specyficzna, więc jeśli coś napiszę to dla Ubuntu, a do innych dystrybucji trzeba będzie to przerobić. No i nie próbowałem nowszych wersji niż 10.04 uruchamiać na VirtualBox, a mogą być problemy z grafiką 3D i nie wiem czy będę w stanie uruchomić wersje od 13.04 wzwyż.

[suore]

Mnie bardziej ciekawi po jakie licho w wymaganiach jest xorg :>
Aplikacji nie pisze się pod serwery wyświetlania, tylko pod bibliotekę np. wysokopoziomową jak QT4/5/QML, lub niskopoziomową jak SDL2.

[lucekk]

Odświeżając temat, gg i tak jest w tyle bo nie obsługuje nowego standardu renderowania ikon w trayu. Na Ubuntu jest na to brzydki hack do qt5, który ratuje sytuację, ale zalecane jest jendak przeportowanie aplikacji na qt5.