User Rights ...

[Lux]

Hi folks,

some of my s9y-installations are "out of sync" concerning user rights.

My providers gives me a ftp user, who is able to upload, download and delete own files. The webserver runs with an other user.

So, if the php script (running with the rights of the webserver user) creates files, i am not able to delete them and vice versa.

Spoken in terms of ownership:

Which directories must be owned by the webserver and which must be owned by the ftp user (regarding updates, etc.(.

Thanks for any support

Dirk

[garvinhicking]

Please read our FAQ, http://www.s9y.org/11.html#A15

Best regards,
Garvin

[Lux]

Please read our FAQ, http://www.s9y.org/11.html#A15

Hi Garvin,

great! Thanks a lot.

Will it be possible to divide plugins into two subdirectories? One with the delivered plugins, which can be overwritten with an update. And one with the plugins written by spartacus.

The point is, that some users have to make a support call for "chown"-command.

Example:

• new version of s9y comes

• ftp-user uploads

• support call to chown to webserveruser, alternatively set rights to 777

• spartacus updates, new files are owned by webserveruser

• new version arrives

• support call to chown to ftpuser

• upload will not work without support call, cause ftpuser does not have the rights to chmod files owned by webserveruser

I think you will have to record two version numbers in database. Spartacus version of plugin and "factory delivered" version. The higher version number tells which plugin to use.

Dirk

[garvinhicking]

Hi!

The point is, that some users have to make a support call for "chown"-command.

Does the mentioned fixperm.php script not help you?

When uploading a new s9y version, the plugins downloaded by spartacus will not be overwritten, so there should be no conflict. Because spartacus plugins are not contained in the release file!

Regards,
Garvin

[Lux]

Does the mentioned fixperm.php script not help you?

I had problems executing the script. ("Basedir restrictions ...", perhaps you remember the thread of october).

When uploading a new s9y version, the plugins downloaded by spartacus will not be overwritten, so there should be no conflict. Because spartacus plugins are not contained in the release file!

I thought, that I once saw an update of a "factory plugin"to be updated through spartacus.

Dirk

[garvinhicking]

Hi!

I had problems executing the script. ("Basedir restrictions ...", perhaps you remember the thread of october).

This should not happen if you specify the right path to your serendipity_config_local.inc.php file. How does your fixperm.php exactly look like? Only "Safe Mode" could block the fixperm.php script...but safe mode sucks anyways and it's going to be removed in future PHP versions.

I thought, that I once saw an update of a "factory plugin"to be updated through spartacus.

We did outsource a few (VERY few) plugins with the 0.8 release somewhen. Blogpdf is the only plugin I can remember, though....but that's the only possibility of how a outdated core plugin could've been updated.

Best regards,
Garvin

[Lux]

This should not happen if you specify the right path to your serendipity_config_local.inc.php file. How does your fixperm.php exactly look like? Only "Safe Mode" could block the fixperm.php script...but safe mode sucks anyways and it's going to be removed in future PHP versions.

"Safe Mode" ist turned off, php-version is 4.4.0.

The errror is

Code: Select all

Warning: chmod(): Operation not permitted in <correct path>/fixperm.php on line 2

We did outsource a few (VERY few) plugins with the 0.8 release somewhen. Blogpdf is the only plugin I can remember, though....but that's the only possibility of how a outdated core plugin could've been updated.

Ok. Everything ist fine, if this is history. I am using version 0,9,1 of s9y.

Dirk

[garvinhicking]

Hi!

"Safe Mode" ist turned off, php-version is 4.4.0.

The errror is

Code: Select all

Warning: chmod(): Operation not permitted in <correct path>/fixperm.php on line 2

Ah, okay. That's a different error message than I anticipated. Seems the chmod() function call is forbidden via your sysadmin's PHP config.

In that case, this system's server setup is a bit screwed, because there really is no way to "fix" files created by the webserver on your own. Support requests are the fault of your sysadmin then, I'm very sorry to say that.

Best regards,
Garvin

[Lux]

Ah, okay. That's a different error message than I anticipated. Seems the chmod() function call is forbidden via your sysadmin's PHP config.

In that case, this system's server setup is a bit screwed, because there really is no way to "fix" files created by the webserver on your own. Support requests are the fault of your sysadmin then, I'm very sorry to say that.

Hmpf, I think I will have to look for a VServer offering.

Thanks for your support.

DIrk