Topic: Pydio - WSOD after server migration

[Charles2008]

I have just used Affa to move SME8 from one server to a newer one, using the instructions here:
http://wiki.contribs.org/Moving_SME_to_new_Hardware

As expected, all ibays - contents, permissions, passwords are replicated.

SOGo, Shared Folders and Pydio and various contribs that I have installed to monitor 'server health' - all non-ibay - were not transferred (as expected).

SOGo and Shared Folders - I have reinstalled the contribs and data is there and contrib is now working.

I am having a problem with Pydio (formerly Ajaxplorer). I have followed the instructions in the page below (which I have followed quite recently with success) and am now getting a white screen:
http://wiki.contribs.org/Pydio

PHP logs - /var/log/messages:

Code: [Select]

Nov  6 11:31:09 server httpd: PHP Warning:  require_once(/etc/pydio/bootstrap_context.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: Permission denied in /usr/share/pydio/base.conf.php on line 27
Nov  6 11:31:09 server httpd: PHP Fatal error:  require_once() [<a href='function.require'>function.require</a>]: Failed opening required '/etc/pydio/bootstrap_context.php' (include_path='.:/usr/share/pear-addons:/usr/share/pear') in /usr/share/pydio/base.conf.php on line 27
Nov  6 11:31:26 server httpd: PHP Warning:  require_once(/etc/pydio/bootstrap_context.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: Permission denied in /usr/share/pydio/base.conf.php on line 27
Nov  6 11:31:26 server httpd: PHP Fatal error:  require_once() [<a href='function.require'>function.require</a>]: Failed opening required '/etc/pydio/bootstrap_context.php' (include_path='.:/usr/share/pear-addons:/usr/share/pear') in /usr/share/pydio/base.conf.php on line 27

/usr/share/pydio/base.conf.php on line 27   ...   reads

Code: [Select]

require_once(AJXP_CONF_PATH."/bootstrap_context.php");
Any pointers would be very welcome 
Charles

[Charles2008]

Ok, I think that I may have found the problem:

In the http logs, there is this entry:
/var/log/httpd/error_log

Code: [Select]

[Wed Nov 06 11:31:03 2013] [warn] RSA server certificate CommonName (CN) `server.xyz.com' does NOT match server name!?
yes, I remember that when I set up my new server, I used a different domain name - actually it is my test server and isn't yet linked to a domain. I decided to change the name so as not to have any possibility of a 'clash' - now, having done the migration, I can see that this might create problems.

I seem to remember that if I enter the Server Console on the server itself that I can change this setting.
Does this sound like the right course of action?

[Charles2008]

So, on the server itself, I entered as admin and:
Server Console > Configure this server

...   and the current configuration is of the original server (prodserver). Actually, this makes sense, but then doesn't explain my problem.

Sorry, back to 'square one' - I still have a problem which I don't understand.
Charles


Further thought: could this be that in the AFFA migration, although it seems to have completely replicated the original server (in a slightly degraded state - i.e. the admin needs to reinstall non-ibay contribs) and original server settings, the 'RSA server certificate' hasn't been migrated?? Or am I talking nonsense.

[Daniel B.]

The warning about the RSA server certificate CommonName (CN) can be ignored. It's not fatal, and it's not even an error (just a warning). For Pydio, the problem is a permission error on /etc/pydio/bootstrap_context.php. This file should be owned by root:apache with permission 660. You're probably hitting this bug: http://bugs.contribs.org/show_bug.cgi?id=7932. If that's the case, /etc/pydio/bootstrap_context will be owned by root:root, so apache cannot read it

[guest22]

SOGo, Shared Folders and Pydio and various contribs that I have installed to monitor 'server health' - all non-ibay - were not transferred (as expected).

Charles2008,

please note the Include[0] option mentioned on the Affa wiki page. You _can_ include the complete /opt directory and much more. Worked for me on on all contribs installations in /opt.

1. Unrise
2. Remove manually installed contribs
3. post-upgrade, reboot
4. Adjust Job file to have Include[0], Include[1] etc statements to include your non-Ibay locations
5. Run job to update SME Server db paramaters (e.g. /root/jobname-job.pl)
6. Affa --run jobname-job.pl
7. Affa Rise
8. post-upgrade and reboot

HTH

Cheers,
guest

[Charles2008]

@Daniel B
Thank you for your help. I have followed your instructions   ...

Before:   ls -al /etc/pydio

Code: [Select]

total 72
drwxrwx---  3 root root  4096 Nov  6 11:31 .
drwxr-xr-x 87 root root 12288 Nov  6 13:36 ..
-rw-rw----  1 root root  2291 Oct 14 20:17 bootstrap_conf.php
-rw-rw----  1 root root  5058 Oct 23 16:06 bootstrap_context.php
-rw-r--r--  1 root root   396 Nov  6 10:37 bootstrap_plugins.php
-rw-r--r--  1 root root  5335 Nov  6 11:31 bootstrap_repositories.php
-rw-rw----  1 root root   298 Oct 23 16:06 conf.editor.imagick.inc
-rw-rw----  1 root root  3204 Oct 14 20:17 extensions.conf.php
-rw-rw----  1 root root 12993 Oct 14 20:17 mime.types
drw-rw----  2 root root  4096 Nov  6 10:32 templates
-rw-rw----  1 root root    26 Oct 14 20:17 VERSION

Code: [Select]

chown root:www /etc/pydio/bootstrap_context.php
chmod 0660 /etc/pydio/bootstrap_context.php
After:   ls -al /etc/pydio

Code: [Select]

total 72
drwxrwx---  3 root root  4096 Nov  6 11:31 .
drwxr-xr-x 87 root root 12288 Nov  6 14:36 ..
-rw-rw----  1 root root  2291 Oct 14 20:17 bootstrap_conf.php
-rw-rw----  1 root www   5058 Oct 23 16:06 bootstrap_context.php
-rw-r--r--  1 root root   396 Nov  6 10:37 bootstrap_plugins.php
-rw-r--r--  1 root root  5335 Nov  6 11:31 bootstrap_repositories.php
-rw-rw----  1 root root   298 Oct 23 16:06 conf.editor.imagick.inc
-rw-rw----  1 root root  3204 Oct 14 20:17 extensions.conf.php
-rw-rw----  1 root root 12993 Oct 14 20:17 mime.types
drw-rw----  2 root root  4096 Nov  6 10:32 templates
-rw-rw----  1 root root    26 Oct 14 20:17 VERSION
...   still getting the white screen.

[Daniel B.]

As you can see, there's a lot of files which should be readable by apache. The problem here is your missing apache group (see the bug I mentionned). Once this is fixed, you'll have to run:

Code: [Select]

rpm --setugids --setperms pydio smeserver-pydio
signal-event webapps-update

But first, you need to have the apache group fixed

[Charles2008]

Hi HF,

I am SO interested in that bit of information that had somehow escaped me. It would make the whole Affa migration so much easier - it is pretty easy already (although I am a little disappointed to be having my Pydio issue - it will probably turn out that it is totally user error  ).

I am hoping that I don't have to use your technique - but it is good to know it is there if there isn't an easier solution. Thank you for detailing it though.
Rgds
Charles

[Charles2008]

Ok, I have read the (very recent) bug and re-read bits of it and am not sure that I am clear on what the solution is - this seems like it is an ongoing situation.

BTW, for clarity:

Code: [Select]

[root@server ~]# rpm -q httpd
httpd-2.2.3-83.el5.centos

From bug report -
"I suspect we are seeing a backup/restore issue here, resulting in missing 'apache' group."
"I then did yum update, followed by the signal-event ... after which the apache group was gone."
"I cannot see at which point the apache group was removed, although by time of the post-upgrade event it was gone."
"Experiencing same situation, but with a restore from sme8."

...  does this mean I should file a bug report?

Basically, it looks as though I have a bigger problem than I had realised.  Perhaps HF's method is the way to go, after all.

[Daniel B.]

do you have an apache group on your system ? (getent group | grep apache). If not, you hit the same bug, so you shouldn't open a new bug but you can comment on the existing one. The problem is not just with Pydio, and you'll have problems with a lot of other web applications until this is fixed

[Charles2008]

Code: [Select]

[root@server ~]# getent group | grep apache
[root@server ~]#

Am I right to assume that this 'no response'  means that I don't have apache group?

[Daniel B.]

Yes, you're affected by bug 7932

[Charles2008]

Does this potentially mean that everyone who has done a recent Yum update has it   ...   Daniel, you might have it too ... 

Seriously, isn't it odd that two other contribs - SOGo and Shared Folders seem ok? Why would it just effect Pydio (so far)?

[Daniel B.]

Does this potentially mean that everyone who has done a recent Yum update has it   ...   Daniel, you might have it too ... 

No, I'm not affected. AFAIk, only backup/restored machine can be affected (maybe not all of them)

Seriously, isn't it odd that two other contribs - SOGo and Shared Folders seem ok? Why would it just effect Pydio (so far)?

No, nothing odd there, only contribs which use the apache group are affected. it's not very common to use the apache group, but a few webapp I maintain does use it

[Charles2008]

HF

please note the Include[0] option mentioned on the Affa wiki page. You _can_ include the complete /opt directory and much more ...

I don't see the include[0] on the 'Moving SME to new Hardware' page that I used but, as you say, it is mentioned on the Affa wiki page.
http://wiki.contribs.org/Affa

How and when would one use the include[0] option when following the 'Moving SME to new Hardware' instructions?

(I seem to remember that there was a reason for not including the SME contribs in the 'Moving SME to new Hardware' - yes, I think it was in the case of people who were moving from one version to a newer version - that their contribs might not work (I guess people often move servers and upgrade at the same time - minimising disruption). Therefore, if they reinstall contribs manually, there is a higher likelihood that they will reinstall the ones that are compatible with the upgraded OS.)

I think that this will still be effected by the bug Daniel mentions. But it would be good in other circumstances.
Charles

[guest22]

Charles,

with the knowledge you have from 'Moving to new hardware', please consider the Affa wikipage a more in depth explenation of all options.

Key is to look at /root/prodserv-job.pl (as per 'Moving to new hardware' page). Simply add the 'Include[0], [1] etc statements as per the Affa wiki page.

Once you have adjusted your 'perfect' /root/prodserv-job.pl, issue affa --make-cronjobs and go from there.

Actually, you should have started from the Affa page and then move on to the 'Move...' page But I'm sure that with patience and logic you will get it done.

And yes, the bug Daniel is referring to will exist....

Cheers,
guest

[Charles2008]

@HF
Thanks, I will have to take a closer look at Affa and the possibility of backing up more than the ibays.

@Daniel
Thanks for your help and info. I think that I will have to wait for a bug fix for the back-up/restore routines.
Maybe it's time to upgrade to 8.1b2 

[john56]

hi everybody,
no issue about this bug apache ?

[guest22]

hi everybody,
no issue about this bug apache ?

That bug is not resolved yet.

[stephdl]

hi everybody,
no issue about this bug apache ?

plop john :p

[chrislaurie]

Just a note: you cannot add the Include[0] = /opt in the pl file because the Moving server to new hardware does not create the prodserv.pl file. It is stored in the db and created when you do affa --run prodserv

The correct way to add includes to affa with the Moving to new hardware is to use the db as such:

Code: [Select]

[root@smeserver ~]# db affa setprop prodserv Include[0] /opt

assuming you used the name prodserv for the job.

See this thread: http://forums.contribs.org/index.php/topic,50340.0.html