[gesloten] modules zijn niet bij te werken

[frankmanl]

Bij twee websites, gehost bij een en dezelfde host, heb ik problemen bij upgraden van modules.
De sites zijn opgezet in 2008 en 2010, met de toenmalige versies, en in de loop van de jaren consequent geupgrade.
Ze maken nu beide gebruik van versie 1.10.3.
Ik krijg bij meerdere, zo niet alle, modules de melding dat downloaden van de nieuwe versies niet mogelijk is - naar ik begrijp uit het forum is dat een rechtenprobleem.
Wanneer ik het via xml wil doen krijg ik een melding als Kan geen bestand aanmaken (rechtenprobleem?) /home/httpd/vhosts/<domeinnaam>/httpdocs/modules/CGExtensions/templates/orig_sortablelist_template.tpl.
Dat bestand heeft als eigenaar de domeinhouder en als authorisatie rw-r--r--. Ik zie niet wat daarmee mis zou zijn, maar het werkt niet.

In het overzicht van geïnstalleerde modules staat bij vrijwel alle modules Geïnstalleerd. Kan niet verwijderen.
CMSMS biedt ook de mogelijkheid de rechten van de modules te wijzigen, maar als ik dat probeer krijg ik de melding Kan de rechten van sommige bestanden niet wijzigen.

Als laatste zou ik nog willen opmerken dat een van de modules (Gallery) als eigenaar Apache heeft. Dat is tevens de enige module waar níet bij staat dat hij niet kan worden verwijderd en die niet de optie Wijzig rechten aanbiedt en die ik op 5 augustus gewoon heb kunnen bijwerken naar versie 1.6. (Goed werk, Jos!)
Eerder hadden de meeste modules als eigenaar Apache - dat is een jaar of twee geleden door de host eens omgezet naar de domeinhouder toen ik ook problemen had met o.m. upgraden.

Ik wil deze problemen graag opgelost hebben, maar krijg dat zelf niet voor elkaar. Van de host krijg ik matige ondersteuning ("Er is geen specifieke oplossing voor, buiten consistent werken.") en eerlijk gezegd zijn er meer redenen waarom ik er weg zou willen, maar dan wil ik wel eerst de site helemaal up to date en werkend hebben, zodat ik een goede kopie kan maken.

Is er iemand die met mij (in een PM-sessie bijv.) zou kunnen kijken waar die rechtenproblemen nou uit bestaan? En hoe ze kunnen worden opgelost?

Frank

[Jos]

Het gaat inderdaad om de eigenaar, die moet in jouw geval Apache zijn.

Waarschijnlijk heb je ooit een backup terug moeten zetten? Dat zou een oorzaak van het probleem kunnen zijn.

Soms kan de eigenaar aangepast worden als je eerst òf via de CMSms FileManager òf via je FTP programma de rechten van mappen recursief (incl inhoud) op 777 zet.

Sommige hosts bieden via hun admin panel ook een filemanager aan waarmee je soms rechten kunt aanpassen.

Als dat allemaal niet kan, dan moet jouw hoster je toch weer ondersteuning bieden door de eigenaar aan te passen. Maar let op: dat moet alleen voor modules die niet in de core zijn inbegrepen.

Alternatief is dat je de zip-bestanden van modules download in de Forge, en via FTP gaat updaten. Maar dat is geen oplossing voor je probleem... meer een workarround.

Tot zover mijn matige kennis van rechten en eigenaren...

[Rolf]

lijkt inderdaad op http://forum.cmsmadesimple.org/viewtopi ... 52&t=45569 :-/

[erpee]

Dat rechtenprobleem kan hardnekkig zijn. Wat bij mij vaak werkt is via mij panel bij de host (Cpanel, Direct Admin) de rechtenaanpassen. Daar werkt het (meestal) wel.

Suk6

[frankmanl]

Heren, dank voor de reacties. Ik duik er van het weekeinde eens in.

[frankmanl]

Het zomerse weer ten spijt toch maar aan deze klus begonnen.
Door bij een module (FormBuilder) de hele map op 777 te zetten was hij weer up te graden via de ModuleManager. De melding Kan niet verwijderen is weg. Ik heb daarvoor de eigenaar niet te hoeven wijzigen (wat overigens ook niet mogelijk is via het PLESK-beheerpaneel van de host).
Vervolgens heb ik in de config.php de default map permissies gewijzigd, zoals Rolf aangaf:

Code: Select all

$config['default_upload_permission'] = '777';

en de UMASK op 000 gezet.
Ik kon vervolgens een nieuwe module installeren via de ModuelManager en deze ook weer verwijderen - precies hoe het hoort. Deze nieuwe module kreeg als eigenaar Apache.

Mijn probleem met deze host lijkt hiermee opgelost. Ik ben echter wel nog benieuwd of deze wijzigingen verdere consequenties hebben.
Kan ik bijvoorbeeld het hele cms gewoon upgraden, of zitten daar nog addertjes onder het gras? Rolf schrijft bijv. bij punt 1 (CHMOD naar 777)

Na het uploaden van bestanden tijdens een upgrade van het CMS, moet je deze stap herhalen! Pas daarna het upgrade proces starten.

Maar het betreft hier wel een bericht uit juli 2010...