Wspólny katalog gier


(Szeryfuniu2) #1

Witam serdecznie wszystkich forumowiczów.

Mam problem, być może nawet nie do rozwiązania, ale postaram się wszystko opisać i nakreślić o co mi chodzi.

Posiadam na komputerze system Linux Mint 17.2, oraz zainstalowana aplikację PlayOnLinux. W aplikacji mam gry w które gram i jest tego sporo, pod względem zajętości na dysku. Wszystko byłoby ok, gdyby nie to, że na komputerze jest jeszcze 3 innych użytkowników i oni również grają w większość tych samych gier. Miejsce na dysku się kurczy więc pomyślałem sobie by zrobić dowiązania symboliczne do mojego katalogu: "~/.PlayOnLinux". Niestety, o ile każdy posiada teraz dostęp jakby do mojego zestawu gier, o tyle nikt nie może zagrać, ponieważ gry się nie odpalają. Pomijam że przy robieniu linków symbolicznych musiałem zmieniać prawa dostępu, bo wtedy nikt nie miał dostępu do tego katalogu. Gdy odpalę grę przez "debuguj", dostaję informację że nie jestem właścicielem plików, co jest logiczne bo bo właściciel to jestem ja, a nie inni użytkownicy.

Teraz meritum. Jak zrobić by wszyscy pozostali użytkownicy mogli odpalać te gry?

Czy da się zrobić kilku właścicieli tego "~/.PlayOnLinux"?

Jak to ugryźć panowie, bo naprawdę nie wiem, a bardzo mi na tym zależy.

W sieci nie znalazłem nic co by pomogło.

Podsumowując: Zależy mi by biblioteka gier w PlayOnLinux była wspólna dla wszystkich, gdy ja zainstaluję grę, by mogli z niej wszyscy korzystać z tymi samymi ustawieniami.

Bardzo proszę o pomoc.

 

Jestem gotów nawet w ostateczności zainstalować system od nowa. Ponowna instalacja i konfiguracja PlayOnLinux także wchodzi w grę. Naprawdę potrzebuję pomocy,..

Nie ma czegoś takiego jak, no nie wiem, "właściciel: everyone" ?

 


(Fizyda) #2

Na początek pokaż chmody .PlayOnLinux i jego zawartości.

ls -l

 


(Szeryfuniu2) #3

Ok, tylko dopiero o 16.00, teraz niestety jestem w pracy.

Ale, mam tu kompa z Linuksem Mint 17.2 :slight_smile:

Zrobię zaraz drugie konto tak jak w domu, PlayOnLinux też tutaj mam i mam czołgi :slight_smile:

 

core@core-desktop ~ $ ls -l


(Fizyda) #4

Daj jeszcze chmody dla /home/core/.PlayOnLinux


(Szeryfuniu2) #5

Dobra, tutaj w pracy zrobiłem tak jak w domu, czyli:

dowiązanie symboliczne dla drugiego użytkownika, prawa dostępu na 777 dla katalogów i plików wewnątrz, a po uruchomieniu przez debuguj otrzymuję taki komunikat:

[04/11/16 11:11:00] - Running wine-1.7.22 WoTLauncher.exe (Working directory : /home/core/.PlayOnLinux/wineprefix/WorldOfTanks/drive_c/Games/World_of_Tanks)
wine: /home/core/.PlayOnLinux//wineprefix/WorldOfTanks is not owned by you

core@core-desktop ~/.PlayOnLinux $ ls -l


(system) #6

(Szeryfuniu2) #7

Czytałem ten temat, niestety tu nie pomaga, gdyż wszyscy mają już prawo zapisu, odczytu i wykonania.

Problem leży w tym, że dany użytkownik nie jest właścicielem i gra się nie odpala…

 


(nintyfan) #8

Może wypróbuj wine-staging. Jest tam zaimplementowane windowsowska wersja ACL’a. Nie obiecuję, że pomoże.


(Szeryfuniu) #9

Zrobić tak:

Na każdym koncie instalacja tej samej wersji wine, ja np używam gotowej paczki pod grę Age Of Empires III.

Następnie dowiązanie symboliczne dla katalogu “drive_c”, (a nie dla całego PlayOnLinux) dla każdego użytkownika.

Następnie chmod na 777.

Następnie kopiujemy z danego “wine prefix” wszystkie pliki konfiguracyjne wine i playonlinux do katalogu z danym “wine prefix” każdego użytkownika.

Musi działać.

 


(nintyfan) #10

Ja bym zmienił nazwę pliczku wine na wine-real, utworzył skrypt wykonujący:

xhost +localhost

sudo -u wine-real wine-real "$@"

, następnie bym dodał wine-real do sudoers. Na koniec utworzyłbym nowego użytkownika o nazwie wine-real. Nie wiem czy mój skrypt będzie działać, gdyż go nie testowałem. Skrypt na pewno musi jakoś blokować wykonanie przez innego użytkownika, by dwa Wine-server nie korzystały z tego samego prefiksa. Możesz to osiągnąć np. sprawdzając czy polecenie pidof wine-server zwróci określoną wartość, tworząc plik blokady i usuwając go dzięki poleceniu trap, itd.


(nintyfan) #11

Tutaj masz moje rozwiązanie:

Instalujesz wersję z GIT. Instalator ma zależności libgreattao, ale możesz to pominąć i nie kopiować libgreattao do głównego katalogu projektu. Uruchamiasz Installer/create_installer. Jutro wrzucę nową wersję instalatorów.


(hiropter) #12

Nie łatwiej dodać użytkowników do grupy games, a później odpowiednie uprawnienia do plików?


(nintyfan) #13

Nie sprawdzałem, ale czy Wine nie miesza w uprawnieniach do plików? Jeżeli tylko tworzy pliki z maksymalnym spektrum uprawnień do nich, to nie ma problemu.

PS: Pomysł hiropter ma wady. Np. co z wieloma instancjami WineServer lub działaniem wielu procesów tego samego programu?


(hiropter) #14

Ale po co uprawnienia na poziomie 0777? To jak schylić się po mydło w amerykańskim wiezieniu o zaostrzonym rygorze i liczyć na to, że jakiś zwyrodnialec nie zakisi ogórka. Dla katalogów dajesz 0775 (lub jeśli zadziała 0770), dla plików dajesz 0664 (jak poprzednio 0660). Przed najlepiej sprawdzić, które pliki są binarkami i tam dać 0775 (lub 0770).

Co do instancji WineServera, to pytanie z jakimi uprawnieniami jest on uruchamiany (z użytkownika) czy istnieje dedykowane konto (jak np. apache, mysql, ftp), choć w sumie na samo działanie jako procesu nie powinno mieć to kompletnie żadnego wpływu.

Ja jedynie zatroszczyłbym się o stworzenie dowiązań symbolicznych do profili gier, bo te będą się mieszać lub nadpisywać - tym bardziej, że nowe gry stosują zazwyczaj zasadę: jedno konto użytkownika = jedne profil w grze.


(nintyfan) #15

WineSystemWide powoduje, że procesy wine są uruchamiane na uprawnieniach specjalnie do tego celu stworzonego użytkownika.

Dzięki za zwrócenie uwagi - faktycznie, dla każdego użytkownika trzeba tworzyć inne dowiązania i podmieniać je podczas startu. Pomyślę czy powinny być to dowiązania do katalogu prawdziwego użytkownika, ale dla uproszczenia będą to dowiązania do katalogów w katalogu użytkownika WineSystemWide.


(hiropter) #16

To w sumie nie masz się czym przejmować.

Powodzenia i jak skończysz to daj znać jak poszło.