Instalacja GG pod Linuxa (Ubuntu 12.04 LTS PL)

[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]

@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]

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.

[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]

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 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]

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.

[Qrix]

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

[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]

Błędy w odpowiednich działach na forum.

[epsilon]

rety czy my naprawde potrzebujemy instalatora? Skoro i tak uzytkownik musi miec prawa do binarek programu zeby ten sie sam zaktualizowal?
Moze maly skrypcik dla userow z ubuntu, bo wydaje mi sie ze swiezaki chyba zazwyczaj wybieraja wlasnie ubuntu na poczatku.
W dawnych czasach, na pytanie ktora dystybucje linuxa wybrac, odpowiadano "ta sama ktora uzywa twoj lokalny linuxowy guru".

A czy wiadomo orientacyjnie ilu jest linuxowych uzytkownikow natywnego klienta gg? Bo poza nowymi userami (z ubuntu) to chyba
kazdy linuxowiec sobie poradzi z wypakowaniem zipa i zrobieniem skrotu w menu, wedle swoich preferencji...

A gdzie tutaj mozna zglaszac bledy odnosnie naszej linuxowej wersji?
Nie dzialaja mi chmurki powiadomien, do ktorych zdazylem sie juz przyzwyczaic...

[Sweetashny Miszcz]

Sprawdzał ktoś politykę GG odnośnie redystrybucji tego programu? Bo napisanie skryptu do instalacji byłoby bardzo proste. Coś podobnego jest dla flasha pod openSuSE, ściągawka w pliku RPM...

Dla Fedory widzę jak na razie takie ograniczenia:
1/ Użyszkodnik musiałby posiadać zainstalowane repozytorium RPMfusion.
2/ Potrzebne byłoby dowiązanie symboliczne do pluginu flasha.
3/ Zrobić skrypt, który kopiowałby pliki GG w miejsce, gdzie użyszkodnik ma prawa zapisu. ~/.local/opt/GG wydaje mi się dobrym rozwiązaniem.

Tak nawiasem, próbował ktoś zastąpić dla GG adobre flasha gnashem? --nie da się

Czym jest plik siglist, który znajduje się w katalogu GG?

siglist zawiera sumy kontrolne plików programu
GG team nie prowadzi systrybucji oprogramowania poprzez repozytorium, dlatego aplikacja musi mieć autoupdater, który zmienia podpisaną listę sum kontrolnych pliku przy każdej aktualizacji.

Przypominam, że ręcznie instalowane programy umieszcza się w /usr/local

Z teorią dotyczącą /usr/local jest pewien błąd...
Owszem, ręcznie kompilowane i instalowane aplikacje trafiają do /usr/local, aby zapobiec konfliktom z paczkami zainstalowanymi przez rpm, dpkg czy aur. Binarne dystrybucje lecą do /opt. Popatrz na przykład na sposób dystrybucji Chrome czy Earth od Google.

Plik gg.desktop powinien, zgodnie z konwencją, trafić do "/usr/local/share/applications/".

Chciałbym poznać tę konwencję.
Twoje dalsze chore rozważania, co gdzie powinno iść zapewne bierze się stąd, że dopiero wskoczyłeś w ten system i bawisz się w eksperta z certyfikatem typu LPI. Ale usiądź pokornie i popatrz jak na przykład instaluje się steam, który jest podobnie dystrybuowaną aplikacją.

A, i naucz się jak Unity traktuje katalog ~/.local, zanim zaczniesz kogoś objeżdżać za umieszczanie w ~/.local/applications aktywatorów.

AAAA... I JESZCZE POZDRO&POĆWICZ ZA TO STWIERDZENIE:

Umieszczanie wykonywalnych plików w katalogu użytkownika z prawami zapisu do nich jest narażeniem na infekcję. Chyba nie chcecie, by mówiono, że GG na Linuksa roznosi wirusy, nie?

Bardziej wątpliwe jest zachowanie Valve jeżeli chodzi o to, że ich dekoder mp3 wymaga pisania po wykonywalnej przestrzeni adresowej pamięci niż zwykłe prawa +wx. Zasada jest taka, że jak użytkownik jest głupi i tak wpisze

rm -rf

i będzie pozamiatane. Największym szczęściem jest to, że raczej ciężko jest zmusić jądro do zrobienia buby z userlandu.

[epsilon]

@Sweetashny Miszcz
nie zauwazylem takiego zachowania

@wrzomar
Wydaje mi sie, ze gg po uruchomieniu, najpierw sprawdza czy jest nowsza wersja i jesli tak to sciaga, podmienia pliki na nowsze, a potem uruchamia
sie raz jeszcze i dopiero wtedy pojawia sie ekran logowania... wiec jesli mam racje, to nie za bardzo wiem kiedy chcialbys zrobic ta podmianke
wlasciciela... no chyba zeby updater poprosil o "root'a".
Osobiscie mam nadzieje, ze paczka z programem pozostanie taka jak teraz, a dla wymagajacych instalatora pojawia sie skrypty do odpowiednich
dystrybucji. W sumie to uzytkownicy danych dystrybucji, mogli by zamieszczac na tym forum skrypty przydatne w ich systemach. A ggteam niech sie
skupi raczej na samej aplikacji, tj. poprawkach bezpieczestwa i niedorobkach ...

A plik siglist hmm moze sa tam certyfikaty do ssl, ktore czasem trzeba uaktualnic? Przyznaje ze nie zagladalem do srodka.

[wrzomar]

Mam kilka pytań. Czym jest plik siglist, który znajduje się w katalogu GG? Dlaczego gg wymaga praw zapisu do tego pliku, żeby się uruchomić? Dlaczego ten plik nie znajduje się w katalogu .gg użytkownika? Przez ten jeden nieszczęsny plik z gg nie można korzystać na koncie gościa. Fajnie, że zrobiliście skrypcik, który integruje z Unity, ale ta integracja jest chyba trochę przestarzała. Chodzi mi o trik z systray-whitelist, który chyba nie działa w najnowszych wersjach (chyba, bo używam 12.04, a w systray-whitelist mam ['all']). Prawidłowy sposób to umieszczenie pliku gg w katalogu "/usr/share/indicators/messages/applications/", który zawiera ścieżkę do pliku gg.desktop (w pliku gg.desktop wpis Icon musi mieć wartość gg, żeby ikona była widoczna, bo inaczej nie będzie - wymaga do chociażby dowiązania symbolicznego /usr/share/pixmaps/gg.png wskazującego na ikonkę). Powinniście podać instrukcję jak zainstalować gg dla całego systemu, jednocześnie zabezpieczając program przed zapisem ze strony zwykłych użytkowników - w razie aktualizacji można zmienić na krótko właściciela na bieżącego użytkownika i po aktualizacji przywrócić właściciela root. Przypominam, że ręcznie instalowane programy umieszcza się w /usr/local, więc gg powinno wylądować w /usr/local/share/GG, a odpowiedni skrypcik gg uruchamiający gghub w "/usr/local/bin/", czyli "/usr/local/bin/gg". Plik gg.desktop powinien, zgodnie z konwencją, trafić do "/usr/local/share/applications/". Umieszczanie wykonywalnych plików w katalogu użytkownika z prawami zapisu do nich jest narażeniem na infekcję. Chyba nie chcecie, by mówiono, że GG na Linuksa roznosi wirusy, nie?

[Sweetashny Miszcz]

Nie wiem czy to bug czy feature, ale reklama wyświetla się po połączeniu dwukrotnie. (x86_64 AKA amd64)