Instalacja GG pod Linuxa (Ubuntu 12.04 LTS PL)

[Sweetashny Miszcz]

rety czy my naprawde potrzebujemy instalatora? Skoro i tak uzytkownik musi miec prawa do binarek programu zeby ten sie sam zaktualizowal?

Steam rozwiązuje ten problem poprzez udostępnianie w pakiecie skryptu, który, w przypadku braku zainstalowanego programu w katalogu użytkownika, pobiera i instaluje go. W przeciwnym wypadku uruchamia program z katalogu domowego.

Ktoś odpowie na pytanie dot. warunków dystrybucji GG?

[Qrix]

Myślę, że nikt nie odpowie na żadne pytania bo robicie zbiorczy temat Lepiej założyć oddzielny dotyczący zagadnienia dytrybucji.

[wrzomar]

Dzięki Miszczu za tę konstruktywną krytykę Nie mam zamiaru brać udziału w tej świętej wojnie - /opt vs /usr/local - ale w /opt umieszczane są także zamknięte programy (oraz LibO z TDF) instalowane przez menadżera pakietów, więc może wystąpić kiedyś konflikt, np. gdy ktoś wpadnie na pomysł stworzenia paczek deb lub rpm z GG. W /usr/local jest odzwierciedlona struktura z /usr, a skoro do pełnej integracji potrzeba sporo plików w różnych miejscach, lepiej żeby były one jakoś uporządkowane i "bliżej" siebie, ale jak ktoś chce to niech sobie gg trzyma gdzie chce, a na dysku zrobi taki burdel, że nikt nie będzie w stanie tego opanować. Nie wiem dlaczego akurat tak często odwołujesz się do Steam, bo GG to nie Steam, zwłaszcza, że jeśli w Valve popełniają gorsze błędy, to może nie warto ich naśladować. Używanie programu, który mógł zostać podmieniony, jest tak samo niebezpieczne jak serwer z błędem, który powoduje wykonanie dowolnego kodu, chociaż nie spowoduje awarii systemu, ale może stworzyć botnet do rozsyłania spamu albo gorzej. Jak inni twórcy oprogramowania też zaczną tak iść na łatwiznę, to trzeba będzie zacząć instalować antywirusy na Linuksie i to takie, które będą sprawdzać każdy otwierany plik wykonywalny, a nie tylko skanery na żądanie.

@epsilon
Nie wiem co się wydarzy gdy pojawi się aktualizacja, bo jeszcze jej nie było, ale wolę, żeby to się odbyło na moich warunkach.

[Sweetashny Miszcz]

Nie mam zamiaru brać udziału w tej świętej wojnie - /opt vs /usr/local - ale w /opt umieszczane są także zamknięte programy (oraz LibO z TDF) instalowane przez menadżera pakietów, więc może wystąpić kiedyś konflikt, np. gdy ktoś wpadnie na pomysł stworzenia paczek deb lub rpm z GG.

Nie ma wojny. Jeżeli coś się instaluje z własnymi wersjami obiektów współdzielonych (jak Chrome, Earth, Xilinx, przy czym GG też spełnia ten warunek) to powinno lecieć do /opt.
Jakby zainstalować takie GG w /usr/local to coś na 100% mogłoby nadpisać xulrunnera.

W /usr/local jest odzwierciedlona struktura z /usr, a skoro do pełnej integracji potrzeba sporo plików w różnych miejscach, lepiej żeby były one jakoś uporządkowane i "bliżej" siebie, ale jak ktoś chce to niech sobie gg trzyma gdzie chce, a na dysku zrobi taki burdel, że nikt nie będzie w stanie tego opanować.

W roocie, tj. /bin, /sbin, /lib etc. trzymane są wszystkie pliki niezbędne do startu systemu i zamontowania /usr. /usr/local zawiera programy dodane przez administratora, które nie wchodzą w skład dystrybucji. Teoretycznie system powinien działać tak samo sprawnie po wywaleniu /usr/local jak zwykle. Jak wspomniałem wcześniej - GG nie może ładować obiektów współdzielonych do /usr/local/lib(64), dlatego powinno być w swoim zorganizowanym miejscu, gdzieś w /opt. Poza tym dla mnie bardziej uporządkowaną formą instalacji jest wrzucenie tego do /opt, zamiast rozwalenia po całym /usr/local.

Nie wiem dlaczego akurat tak często odwołujesz się do Steam, bo GG to nie Steam, zwłaszcza, że jeśli w Valve popełniają gorsze błędy, to może nie warto ich naśladować.

Steam jest:

• aplikacją zamkniętą
• dystrybuowany z własnymi wersjami obiektów współdzielonych
• aktualizowany przy pomocy własnego auto-updatera

Prawie jak GG, c'nie? Poza tym, w Valve i GG pracują ludzie, tacy jak ja czy ty. Ludzie popełniają błędy, ale z sukcesów trzeba brać naukę.

Używanie programu, który mógł zostać podmieniony, jest tak samo niebezpieczne jak serwer z błędem, który powoduje wykonanie dowolnego kodu, chociaż nie spowoduje awarii systemu, ale może stworzyć botnet do rozsyłania spamu albo gorzej. Jak inni twórcy oprogramowania też zaczną tak iść na łatwiznę, to trzeba będzie zacząć instalować antywirusy na Linuksie i to takie, które będą sprawdzać każdy otwierany plik wykonywalny, a nie tylko skanery na żądanie.

GG posiada mechanizmy kontrolujące integralność swoich plików. Będąc rozsądnym człowiekiem nigdy nie uruchomisz programu, do którego nie masz zaufania inaczej, niż w piaskownicy. Używanie własnego auto-updatera nie jest pójściem na łatwiznę - wręcz przeciwnie, łatwiej jest korzystać z menadżera pakietów, który jeszcze sam zależności pociągnie. Relikt tego, że aplikacja była od początku rozwijana pod Windowsem. Używanie Linuksa nie zwalnia Cię od instalacji antywirusa.

[wrzomar]

Nie nadpisze jeśli nie będzie rozbite, a różnica czy katalog GG z całym gadugadu będzie w /usr/local/share/ czy w /opt ogranicza się do ścieżki dostępu do programu. W tej chwili GG jest samodzielnie instalowaną aplikacją, która nie udostępnia kodu, więc nie może być kompilowana przez szarego użytkownika, tylko brak kodu dyskwalifikuje ją od statusu "samodzielnie kompilowanej". Jeśli GG będzie spaczkowane (nowe słowo) to powinno trafić do /opt, ale mam pewne opory przed samodzielnym wrzucaniem do /opt skoro jakaś paczka mi go może nadpisać, ale na razie nie ma takiej paczki, więc może sobie być w /opt. Mógłbyś wyjaśnić jak GG potwierdzi integralność plików kiedy nie będzie sobą tylko specjalnie spreparowaną wersją GG? Przy okazji możesz przekonać nieprzekonanych o konieczności instalowania antywirusa na Linuksie. Powodzenia

PS. Lepszym przykładem mógłby być Tl... Ten Którego Nazwy Nie Wymieniamy, który jest zamkniętym programem, dostarcza własne biblioteki, ma auto-aktualizację i ląduje w /opt jeśli jest instalowany przez administratora.

[Sweetashny Miszcz]

Nie nadpisze jeśli nie będzie rozbite, a różnica czy katalog GG z całym gadugadu będzie w /usr/local/share/ czy w /opt ogranicza się do ścieżki dostępu do programu.

/share jest dla szablonów, dokumentacji, przykładowej dokumentacji, plików współdzielonych z innymi aplikacjami... GG nie ma czego tam szukać.

W tej chwili GG jest samodzielnie instalowaną aplikacją, która nie udostępnia kodu, więc nie może być kompilowana przez szarego użytkownika, tylko brak kodu dyskwalifikuje ją od statusu "samodzielnie kompilowanej". Jeśli GG będzie spaczkowane (nowe słowo) to powinno trafić do /opt, ale mam pewne opory przed samodzielnym wrzucaniem do /opt skoro jakaś paczka mi go może nadpisać, ale na razie nie ma takiej paczki, więc może sobie być w /opt.

Nie wiem w jakim celu jakakolwiek paczka mogłaby kiedykolwiek napisać katalog /opt/GG.

Mógłbyś wyjaśnić jak GG potwierdzi integralność plików kiedy nie będzie sobą tylko specjalnie spreparowaną wersją GG?

Właściwie te same pytania można zadać takim skryptom jak ~/.bash_logout, ~/.bash_profile czy ~/.bashrc.

Przy okazji możesz przekonać nieprzekonanych o konieczności instalowania antywirusa na Linuksie. Powodzenia

Antywirusy dla Linuksa pomagają wykryć rootkity.

PS. Lepszym przykładem mógłby być Tl... Ten Którego Nazwy Nie Wymieniamy, który jest zamkniętym programem, dostarcza własne biblioteki, ma auto-aktualizację i ląduje w /opt jeśli jest instalowany przez administratora.

Nie wiem czemu Tlen miałby być lepszym przykładem.

[wrzomar]

Bo jest komunikatorem, a nie sklepem z grami? No i można z niego korzystać na koncie gościa, co w GG nie jest możliwe, chyba, że gość będzie za każdym razem pobierał te ponad 40 MB - to chyba lepiej gdyby korzystał z wersji w przeglądarce (tylko po co musi to robić, skoro GG jest zainstalowane). Jak bym zmienił /usr/local/share na /usr/local/lib to uspokoi to Twoje sumienie? Wzorem Firefoksa, który z całym inwentarzem jest w /usr/lib, chociaż są tam też ikony, pliki xml, przykładowe preferencje i inne.

[epsilon]

@Sweetashny Miszcz
moze w okienku o programie bedziesz mial opisane zasady na jakich mozna rozpowszechniac to oprogramowanie.

@Qrix
chyba tylko nas 4-rech to czyta wiec chyba nikt inny nie odpowie. A propos co do tworzenia watku, to utworzylem takowy
odnosnie braku chmurek i tez mi nikt nie odpowiedzial.
Ale racja zaczyna sie robic metlik.

@wrzomar
przyznam szczerze ze co do aktualizacji to sie zasugerowalem tym jak robil to gg11. Uruchamial mi sie po 2x i wtedy sie
zorientowalem, bo to chyba o to chodzilo, ze ostatecznie uruchomila sie nowsza wersja. Odpal sobie gg12 w terminalu, to zobaczysz
app.update przed startem gg12.

@all
Co do lokalizacji gg to tez uwazam, ze jesli juz tak to chcecie miec w "systemie" to powinno to byc w /opt/GG. Czyli w osobnym
katalogu. Rzeczywiscie robi sie nieraz noexec na /home i ma to swoje uzasadnienie. Wiec moze gg powinno wyladowac w /opt
wraz z utworzonym dla niego nowym kontem i grupa. Wtedy uzyszkodnik nie moze go zmodyfikowac. Osobiscie nie chcialbym
zeby bylo potrzeba uruchamiac z roota update gadu. Moze wiec sudo na prawach nowego konta gadu do uruchomienia updatera?

[wrzomar]

@Sweetashny Miszcz
Katalog /opt/GG może kiedyś nadpisać instalator lub pakiet z inną wersją GG, jeśli takowy powstanie i jeśli nie usunie przedtem tego co tam jest to powstanie bałagan.
Oprócz szukania rootkitów będą musiały też sprawdzać GG
Skrypty .bash_logout, .bashrc i .bash_profile są skryptami i łatwiej się je czyta niż kod maszynowy.
@epsilon
Można zrobić właścicielem plików z GG jakiegoś użytkownika systemowego, który będzie służył tylko do upgrade'u GG i updater mógłby mieć setuid, żeby się uruchamiał zawsze jako proces tegoż użytkownika.

Problemem nie jest gdzie wrzucić to systemowe GG, ale plik siglist do którego gg musi mieć prawo zapisu, bo się nie zaloguje do konta. I to właśnie z jego powodu Gość nie może używać GG zainstalowanego w systemie. Jeśli Gość będzie mógł zapisywać do siglist, gdy GG jest w /opt, to zwracam honor. W tej chwili nie może pisać do tego pliku nawet jeśli ma on uprawnienia rwrwrw.

[epsilon]

@wrzomar
Moze lepiej osobne konto+grupe aby byl porzadek. Zreszta chyba nie we wszystkich distrach sa wszystkie konta systemowe.
Co do suid to o ile sie nie myle, Fedora pozbyla sie ich wszystkich na rzecz selinux, albo tak ma byc dopiero. Wiec to tez chyba
nie jest zbyt nowoczesne podejscie.
Mysle ze lepsze bedzie w skrypcie uruchomieniowym gg, komenda sudo (na konto to gadu) zeby sie mogl zaktualizowac,
po czym nastapi dalsze uruchomienie programu juz na prawach uzyszkodnika ktory go uruchomil... Oczywiscie trzeba bedzie
dorzucic linijke do pliku sudoers.

I jeszcze jedno my tu gadu gadu co gdzie powinno byc i na jakich prawach, a przejmowac sie powinnismy tym ze ggteam
wspiera tylko wersje na ubuntu, ktore co jak niektorzy wieszcza oddala sie coraz bardziej od innych dystrybucji. Wiec
kto wie ilu z nas bedzie go moglo sensownie uzywac w dluzszej perspektywie ...
Aha lokalizacja w /opt/GG ma jeszcze inna dobra ceche, latwo usunac gg z systemu, a nie szukac plikow po /usr/local/bin lib...

[Sweetashny Miszcz]

@wrzomar
Ponieważ nie jestem już w stanie walczyć z Twoim brakiem wiedzy i upartym wtrącaniem swoich 5 groszy nie mając najmniejszego pojęcia o tym, co piszesz - przyznaję Ci rację.

[wrzomar]

@Sweetashny Miszcz
Mój brak wiedzy podpowiada mi, że /usr/local/lib różni się od /usr/local/share tym, że ten drugi nie jest przeszukiwany przez ldconfig w poszukiwaniu bibliotek. Popraw mnie jeśli się mylę, ale /opt również nie byłby przeszukiwany, podobnie jak jakiś katalog w katalogu domowym użytkownika, do którego zostałoby wypakowane archiwum z GG, a GG bez tego i tak działałoby.

@epsilon
W /usr/bin lub /usr/local/bin wystarczy jeden plik, który pozwoli na uruchamianie gg bez podawania pełnej ścieżki do niego. Nawet jeśli całe GG umieścić w /opt to i tak pliki gg.desktop oraz ikony będą musiały być porozrzucane po /usr/share. GGTeam wspiera wersję na Ubuntu, ale i tak nie integruje się ona w pełni z Unity (i dobrze, bo wtedy na pewno inni nie mogliby go używać), a używanie systray-whitelist działa w wersjach do 12.10 włącznie.

[epsilon]

@wrzomar @Sweetashny Miszcz
W informatyce mozna robic rzeczy na rozne sposoby zaleznie od potrzeb czy po prostu wiedzy. Ale to nie powod aby toczyc o to swiete wojny.
Na forach linuxowych to juz specyfika, ze poszczegolne klany (uzytkownicy debiana slackware itd itd) udowadniaja innym wyzszosc swojej dystrybucji.
Tak przynajmniej kiedys bylo ale przeciez to do niczego nie prowadzi na dobra sprawe. Malo tego dochodzi w koncu do "wycieczek osobistych".
Roznorodnosc linuxa to jego zaleta i wada, zalezy od tego jakie ma sie priorytety.
Wiec zamiast spierac sie o wyzszosc takich swiat nad innymi, niewazne kto ma w tym przypadku racje, wezmy sie raczej za rozwiazanie
ktore bedzie jesli nie wszystkim pasowac, to przynajmniej nie bedzie utrudniac zycia.

@wrzomar
gg.desktop moze byc chyba przeciez w .local tak samo ikony, chociaz w pliku gg.desktop mozna podac pelna sciezke dla ikon do /opt. Pozostaje kwestia
innych uzytkownikow na kompie, ale to chyba mozna zalatwic podczas pierwszego uruchomienia.
do ldconfig mozna dodac sciezke przeszukiwania do /opt... ale po co, o ile sie nie myle to gg podczas kompilacji dostaje ?wzgledna? sciezke gdzie ma szukac.
A skrypt gg do uruchomienia pobiera sciezke katalogu w ktorym jest jako parametr, zeby pewnie wiedziec gdzie szukac reszty.

A jak ta sprawe rozwiazal skype? W niektorych dystrybucjach widze paczke ze skype. Nie wiem jak teraz ale on sie wczesniej sam nie aktualizowal.
Mysle ze samoaktualizacja ma swoje zalety i to chyba coraz popularniejsze.

[wrzomar]

@epsilon
Skype sprawę rozwiązał tak, że są dwa pakiety: skype i skype-bin - ten drugi 32-bitowy i ukrywa co się w nim znajduje. W drzewie katalogów porozsiewali dokumentację, pomoc, ikony i inne pliki w różnych podkatalogach /usr/share, a skype jest plikiem binarnym w /usr/bin i ma na oko 30MB oraz korzysta z bibliotek współdzielonych (tylko których?), a na inżynierię wsteczną MS reaguje jak diabeł na wodę święconą. Skype aktualizuje się na Ubuntu tak jak inne aplikacje instalowane z repo. Samoaktualizacja ładnie wygląda w Firefoksie prosto od Mozilli, ostatnio w Ubuntu dają najnowsze wersje więc nie wiem czy nadal tak przebiega, ale podczas aktualizacji ściągane były tylko te pliki, które uległy zmianie.
Plik gg.desktop może być w .local, ale wtedy będzie dostępny tylko dla jednego użytkownika, więc plik potrzebny dla Messaging Menu powinien trafić do $HOME/.config/indicators/messages/applications/ i zawierać ścieżkę do gg.desktop. Niestety to menu ma problem ze znalezieniem ikony nawet jeśli w pliku desktop podana będzie pełna ścieżka do niej, łapie tylko jeśli wpis Icon będzie miał wartość np. gg, ale żeby mógł znaleźć w ten sposób ikonę do programu, musi ona znajdować się w pixmaps, w tym przypadku w ~/.local/share/pixmaps wystarczy dowiązanie do gg.png, ale nie wiem czy będzie ten katalog uwzględniany w poszukiwaniu ikon. Dowiązanie, bo nie wiem czy skopiowanie gg.png nie złamałoby prawa. Niestety nie mamy bezpośredniego wpływu na to jak GG działa, więc możemy rozmawiać o miejscach i uprawnieniach. Setuid'u nie można w tej chwili wykorzystać, bo nie ma wydzielonego updater'a, zmiana uid na innego użytkownika na czas aktualizacji również wymaga modyfikacji samego GG, najrosądniejsze jest w tej chwili tymczasowe zmienienie uprawnień/własności do katalogu z GG, jeśli zostanie wykryte, że istnieje nowsza wersja GG, sprawdzenie antywirusem czy jest OK po aktualizacji i ponowna zmiana uprawnień/własności, aby zabezpieczyć przed zmianami.
W skrypcie gg jest ustawiana zmienna środowiskowa GG_PATH, która jest ustawiana na katalog w którym jest uruchamiany tenże skrypt, nie wiem czy ta zmienna jest używana później przez GG po uruchomieniu, we własnym skrypcie można ustawić tę zmienną "na sztywno" na ścieżkę do GG, np. /opt/GG.
Ścieżki do GG do ldconfig nie trzeba podawać, a nawet nie powinno, skoro tam są wersje bibliotek używane tylko przez GG i wyrządziłyby one więcej szkód niż pożytku.
Nie wiem co masz na myśli, mówiąc o załatwianiu przy pierwszym uruchomieniu. Można by było umieścić GG w katalogu do którego pełen dostęp mieliby wszyscy użytkownicy, ale byłoby to jeszcze gorsze rozwiązanie niż trzymanie GG w katalogu użytkownika.

PS. Google dla Chrome i Earth problem aktualizacji rozwiązał tworząc własne repo z Chrome, Earth i resztą. Scribus również tak postąpił dla Ubuntu i Debiana. Niektóre projekty, jeśli licencje na to pozwalają, mają PPA na launchpadzie, ale są one prowadzone przez użytkowników, a nie developerów tych projektów (pewnie są wyjątki, ale żaden mi nie przychodzi do głowy).

[Sweetashny Miszcz]

@wrzomar @Sweetashny Miszcz
W informatyce mozna robic rzeczy na rozne sposoby zaleznie od potrzeb czy po prostu wiedzy. Ale to nie powod aby toczyc o to swiete wojny.
Na forach linuxowych to juz specyfika, ze poszczegolne klany (uzytkownicy debiana slackware itd itd) udowadniaja innym wyzszosc swojej dystrybucji.
Tak przynajmniej kiedys bylo ale przeciez to do niczego nie prowadzi na dobra sprawe. Malo tego dochodzi w koncu do "wycieczek osobistych".
Roznorodnosc linuxa to jego zaleta i wada, zalezy od tego jakie ma sie priorytety.
Wiec zamiast spierac sie o wyzszosc takich swiat nad innymi, niewazne kto ma w tym przypadku racje, wezmy sie raczej za rozwiazanie
ktore bedzie jesli nie wszystkim pasowac, to przynajmniej nie bedzie utrudniac zycia.

Ja lubię spory, tylko argument, że nie dla /opt/GG bo nie mnie zaczyna już denerwować.

@wrzomar
gg.desktop moze byc chyba przeciez w .local tak samo ikony, chociaz w pliku gg.desktop mozna podac pelna sciezke dla ikon do /opt. Pozostaje kwestia
innych uzytkownikow na kompie, ale to chyba mozna zalatwic podczas pierwszego uruchomienia.
do ldconfig mozna dodac sciezke przeszukiwania do /opt... ale po co, o ile sie nie myle to gg podczas kompilacji dostaje ?wzgledna? sciezke gdzie ma szukac.
A skrypt gg do uruchomienia pobiera sciezke katalogu w ktorym jest jako parametr, zeby pewnie wiedziec gdzie szukac reszty.

A jak ta sprawe rozwiazal skype? W niektorych dystrybucjach widze paczke ze skype. Nie wiem jak teraz ale on sie wczesniej sam nie aktualizowal.
Mysle ze samoaktualizacja ma swoje zalety i to chyba coraz popularniejsze.

Ja bym nie dodawał /opt do ścieżki ldconfig, ponieważ GG przychodzi do systemu z własnymi bibliotekami, które już w nim powinny być. Poza tym to i tak jest bezcelowe.
Jedyna rzecz, jaką można by zrobić to zalinkowanie /opt/GG/gg do /usr/bin/gg, jak to robi Chrome.

Skype to jest nieciekawy obiekt... To coś ma zawsze ze sobą problemy zwłaszcza na poziomie, że w paczkach 64-b jest 32-b binarka. Poza tym Skype grzecznie się aktualizuje przez managera pakietów.