[Solved] AddOns user privileges issue in Ubuntu9.10

[Garrett]

It's all installed, thanks for your help! One quick newbie problem - I can't install any Addons - I keep getting an "Access Denied" due to not having the rights for the Addons folder. I've tried "su"ing into root but it doesn't recognise the password I chose in the User Profiles section. Any ideas?

[jervine]

Ubuntu will surely make use of sudo rather than su. You can sudo su - to become root whilst supplying your own user password. You can also simply install the add-ons into ~/.Oolite/Addons

[Garrett]

Thanks - sudo now lets me move things around. Unfortunately, neither placing the Addons in ~/.Oolite/Addons or in /usr/lib/Oolite/Addons works. I know in Windows you're supposed to hold down the Shift key when running Oolite for the first time after installing an Add-on, but that doesn't seem to make much difference in Linux. Any thoughts where I should place the Addons?

Thanks everyone for your help, by the way, it is much appreciated!

[Micha]

Hi Garrett,

AddOns should get installed into

Code: Select all

~/.Oolite/AddOns/<oxp directory>

Ie, OXP "foo" should be in:

Code: Select all

~/.Oolite/AddOns/foo.oxp

A lot of OXPs are packaged into a Zip as:

Code: Select all

  
/foo/
    |- foo.oxp/
       |- <oxp contents>
    |- readme.rtf

So you need to extract the "foo.oxp" subdirectory into your "AddOns" directory, and not the root directory of the zip file.

Important is that only directories ending in ".oxp" will be recognised by Oolite as an OXP.

If this doesn't help, can you please post the contents of your "Latest.log", which should be in:

Code: Select all

~/.Oolite/Logs/Latest.log

Hope this helps

- Micha.

<edit>
Just noticed, you used ~/.Oolite/Addons - it must be ~/.Oolite/AddOns.
</edit>

[Garrett]

Thanks for the advice, this is what happens when you copy directories from a non-case-sensitive OS (Windows) into a case-sensitive one (Linux)!

If I place the AddOns directory in /usr/lib/Oolite then the OXP's get loaded correctly, but only if I run the game using "sudo oolite". If I place the AddOns directory in ~/.Oolite, then I get lots of error messages in the log file, and it can't even load my custom key configuration - for instance:

[gnustep]: 2009-11-06 16:46:04.401 oolite[2328] Failed to recurse into directory '~/.Oolite/AddOns/outrider.oxp' - Permission denied

Oh well, I'm happy enough typing "sudo oolite" to run the game instead of just plain-old "oolite"

[Kaks]

It looks like one or all of the oxp directories were created / copied where they are either by you as another user, or with the help of sudo.

You should get oolite to work without those problems if you change permissions recursively on the ~/.Oolite/AddOns directory tree ( for further info on that see this article http://www.redhat.com/docs/manuals/linu ... rship.html ) .

I'm personally quite uncomfortable with the concept of running any game as super user.

It just seems - well, wrong...

[Micha]

I agree.

Installing OXP's into /usr/lib/Oolite/AddOns should work fine even as a normal user provided everybody has read-permissions to the files and read&execute-permissions to the directories.

Installing them into your own directory (ie. ~/.Oolite/AddOns) is probably easier and better as long as you make sure all files are owned by your user.

You can change the ownership as follows:
1. Open a Terminal window.

2. Note down your user id:

Code: Select all

id -u

3. Note down your group id:

Code: Select all

id -g

4. Change ownership (Note the '.' between the user id and group id):

Code: Select all

sudo chown -R <user id>.<group id> .Oolite/AddOns

Here's an Ubuntu-specific section on file permissions:
https://help.ubuntu.com/community/FilePermissions

[Garrett]

Thanks, I guess this is what happens when you "super-user" to often I sudo deleted the AddOns directory, and then created it as a normal user in ~/.Oolite, and then copied all the OXP's from Windows into it. It all now works fine. Thanks everyone - this is indeed the friendliest forum this side of Riedquat

[_ds_]

4. Change ownership (Note the '.' between the user id and group id):

Code: Select all

sudo chown -R <user name>.<group name> .Oolite/AddOns

That's deprecated usage. IDs may contain ‘.’s.

Code: Select all

sudo chown -R <user id>:<group id> .Oolite/AddOns

Or, since you evidently prefer numbers:

Code: Select all

sudo chown -R $(id -u):$(id -g) .Oolite/AddOns

[Micha]

That's deprecated usage. IDs may contain ‘.’s.

Code: Select all

sudo chown -R <user id>:<group id> .Oolite/AddOns

Or, since you evidently prefer numbers:

Code: Select all

sudo chown -R $(id -u):$(id -g) .Oolite/AddOns

Ah, thanks, didn't know about the deprecated dots. When did they sneak that in?

As for your suggestion of $(id -u) - that won't work.
Since we're running under 'sudo' it'll return 0 (root userid) and not the users' userid.

Anyway, looks like Garrett got it going in his own way

[_ds_]

That's deprecated usage. IDs may contain ‘.’s.

Code: Select all

sudo chown -R <user id>:<group id> .Oolite/AddOns

Or, since you evidently prefer numbers:

Code: Select all

sudo chown -R $(id -u):$(id -g) .Oolite/AddOns

Ah, thanks, didn't know about the deprecated dots. When did they sneak that in?

Not sure. Years ago, though; I think that it's in POSIX 1003.1-2001.

As for your suggestion of $(id -u) - that won't work.
Since we're running under 'sudo' it'll return 0 (root userid) and not the users' userid.

Oh, right. We're in this situation, then:

Code: Select all

$ sudo bash
# sudo chown -R $(id -u):$(id -g) .Oolite/AddOns

You should have said

(Hint: shell substitutions happen first, so sudo (or whatever) doesn't get to see $(…) unless there was quoting to prevent the subsitution.)

[Micha]

Hmm, I had initially tried out a sudo-with-shell-substitution solution and it hadn't worked. I probably made a mistake.. *sigh* I keep making a fool of myself, huh?