update from 2008.0 using update20081

[xmanhattan]

Hello all,

I have tried to update elxis from 2008.0 using update20081 on my local server but unfortunately it stops on step 7.

The message says that the language directory or the permission settings are incorrect but I have set them to 777 and verified that the user settings were correct.

Make the up20081/log.txt file writable (permissions 666).  done
Make up20081/config.php file writable (permissions 666).  done
Turn your Elxis site offline, I assume that mean Yes and not Yes for admin although no one else uses this system.

PHP Version 5.1.6
Apache/2.2.2
mysql 5.0.27
mysqli 5.0.27

A second test installation of Elxis 2008.1 Stable rev2204 [ Nemesis ] works.

What or how can I fix this to proceed?

[Ivan Trebješanin]

The problem is when Elxis tries to create it can't do so if parent dir is not writable. So in this case, try to make parent dir writable just until you finish upgrade.
Example: for backend languages to be successfuly upgraded you should make administrator directory writable (remember to make it back to 755 after install). For frontend languages, parent is public_html... etc.

All the above is workaround for specific server setting.

[babis1]

and for me work like this way, in many cases i had to do 777 and parent folder, maybe its better to do 777 all the directories before updating

[datahell]

Use the integrated chmod tool and do what Ivan told you.
Remove any backup folders (_BACKUP_....) at the end.

[xmanhattan]

Well actually Babis1 was correct.  I had to change the root /public_html folder to 777 and then it worked.

After doing the file system check, it displayed the following:
Warning    administrator/components/com_massmail/admin.massmail.html.php   File needs update!
Warning    administrator/components/com_massmail/admin.massmail.php   File needs update!
Warning    administrator/components/com_massmail/massmail.xml   File needs update!
Warning    administrator/components/com_massmail/toolbar.massmail.html.php   File needs update!
Warning    administrator/tools/defender/config.php   File needs update!
Warning    administrator/tools/defender/language/german.php   File needs update!

and some minor errors.

Didn't the updater update these files?

Also after going to the site tools, updiag, check version, I received the following error:
Fatal error: Call to a member function getText() on a non-object in /var/www/html/administrator/tools/updiag/updiag.class.php on line 65

As for file permissions, normally 775 and 664 are used for directories and files accordingly but I can understand that a cms might need 777 and 666 in some cases but not for the root html directory.

Petros

[datahell]

Hash file is of different version than the actual files. That's why it tells you that some files need update. It's ok, dont worry. We still need to release one more patch and afterwards we will update hash files.

getText(): Has already been fixed but the patch is not yet released. Dont use that feature till a patch is released.

About permissions: To create a file inside a directory that directory must be writable. So, if you need to create a file in the root directory the root directory (public_html) must be writable. That directory dont have to be writable by anyone, just for the user that tries to create the file inside it.

Think of userA and userB as FTP users and nobody as the web server (apache):

dir permissions: 777, owner: nobody, creation of file by userA -> SUCCESS
dir permissions: 777, owner: nobody, creation of file by nobody -> SUCCESS
dir permissions: 755, owner: nobody, creation of file by userA -> DENIED
dir permissions: 755, owner: nobody, creation of file by nobody -> SUCCESS
dir permissions: 755, owner: userA, creation of file by userA -> SUCCESS
dir permissions: 755, owner: userA, creation of file by nobody -> DENIED
dir permissions: 755, owner: userB, creation of file by userA -> DENIED
dir permissions: 755, owner: userB, creation of file by nobody -> DENIED
dir permissions: 755, owner: userB, creation of file by userB -> SUCCESS

[xmanhattan]

Datahell, Ivan, and Babis1,

Thank you for your answers.

With reference to your example of userA, userB, and nobody, that is what happened and by setting the public_html to 777 it did solve that problem and chmod all directories and files to ROOT.  Then afterwards, I simply set the permission back to 775 for the public_html.

The test site on my local server appears to be funtioning normally and I will advise you if I see any trouble areas.

Do I have to wait for the additional patch to update my live site?

[datahell]

We will release one final patch for version 2008.1.
The release date is still unknown.