Upgrade to 5.2.x on CentOS 6.7

[dsudar]

Hi all,

Happy New Year.

I'm contemplating to upgrade my CentOS 6.7 production server from 5.1.4 to 5.2.1. I looked through the docs describing all the stuff with the virtualenv for Python 2.7 and was wondering how problematic it would be to stick with Django 1.6 and the stock Python 2.6. To test that approach, I upgraded my test server by installing Django 1.6 and gunicorn, switched the web config to use wsgi-tcp instead of fastcgi and it looks like everything came up fine and is fully functional. So besides the danger of running a Django version that will not get security fixes (but currently has no known security issues), are there any issues I should be aware of?

I'm planning to upgrade the whole server to CentOS 7 some time soon so would like to avoid all the added complexity of doing the virtualenv stuff at this time.

Thanks,
- Damir

[atarkowska]

Hi Damir,

We recommend you to upgrade, see http://lists.openmicroscopy.org.uk/pipe ... 05782.html. OMERO.web will continue to run with Django 1.6 but we're unable to patch any security vulnerabilities and you would need to take alternative precautions to protect the system.

Ola

[dsudar]

Hi Ola,

After running 5.2.1 for a while under Python 2.6/ Django 1.6, I decided to upgrade per your recommendations to Python 2.7/Django 1.8. So I followed the instructions on: http://www.openmicroscopy.org/site/supp ... ntos6.html

I was doing this in advance of upgrading to 5.2.2.

But clearly I went wrong somewhere. When I try to start the server I get:

[omero@bigimserv ~]$ omero admin start
No descriptor given. Using etc/grid/default.xml
Waiting on startup. Use CTRL-C to exit
.............................
Failed to startup some components after 300 seconds
Calling "stop" on remaining components
Waiting on shutdown. Use CTRL-C to exit

and in master.err:

-! 03/18/16 14:19:04.880 OMERO.Glacier2: warning: unable to contact permissions verifier `BlitzVerifier@BlitzAdapters'
Reference.cpp:1663: Ice::NoEndpointException:
no suitable endpoint available for proxy `BlitzVerifier -t -e 1.1 @ BlitzAdapters'
-! 03/18/16 14:19:04.914 OMERO.Glacier2: warning: unable to contact session manager `BlitzManager@BlitzAdapters'
Reference.cpp:1663: Ice::NoEndpointException:
no suitable endpoint available for proxy `BlitzManager -t -e 1.1 @ BlitzAdapters'
0 IceUtil::Exception::Exception(char const*, int) in /opt/Ice-3.5.1/lib64/libIceUtil.so.35
1 Ice::LocalException::LocalException(char const*, int) in /opt/Ice-3.5.1/lib64/libIce.so.35
2 Ice::NoEndpointException::NoEndpointException(char const*, int, std::string const&) in /opt/Ice-3.5.1/lib64/libIce.so.35
3 /opt/Ice-3.5.1/lib64/libIce.so.35(+0x55bcac) [0x7f3f7b238cac]
4 IceInternal::LocatorInfo::RequestCallback::response(IceInternal::Handle<IceInternal::LocatorInfo> const&, IceInternal::ProxyHandle<IceProxy::Ice::Object> const&) in /opt/Ice-3.5.1/lib64/libIce.so.35
5 IceInternal::LocatorInfo::Request::response(IceInternal::ProxyHandle<IceProxy::Ice::Object> const&) in /opt/Ice-3.5.1/lib64/libIce.so.35
6 Ice::CallbackNC_Locator_findAdapterById<IceInternal::LocatorInfo::Request>::__completed(IceInternal::Handle<Ice::AsyncResult> const&) const in /opt/Ice-3.5.1/lib64/libIce.so.35
7 Ice::AsyncResult::__response() in /opt/Ice-3.5.1/lib64/libIce.so.35
8 IceInternal::OutgoingAsync::__finished() in /opt/Ice-3.5.1/lib64/libIce.so.35
9 Ice::ConnectionI::dispatch(IceUtil::Handle<Ice::ConnectionI::StartCallback> const&, std::vector<Ice::ConnectionI::SentCallback, std::allocator<Ice::ConnectionI::SentCallback> > const&, unsigned char, int, int, IceInternal::Handle<IceInternal::ServantManager> const&, IceInternal::Handle<Ice::ObjectAdapter> const&, IceInternal::Handle<IceInternal::OutgoingAsync> const&, IceInternal::BasicStream&) in /opt/Ice-3.5.1/lib64/libIce.so.35
10 Ice::ConnectionI::message(IceInternal::ThreadPoolCurrent&) in /opt/Ice-3.5.1/lib64/libIce.so.35
11 IceInternal::ThreadPool::run(IceUtil::Handle<IceInternal::ThreadPool::EventHandlerThread> const&) in /opt/Ice-3.5.1/lib64/libIce.so.35
12 IceInternal::ThreadPool::EventHandlerThread::run() in /opt/Ice-3.5.1/lib64/libIce.so.35
13 /opt/Ice-3.5.1/lib64/libIceUtil.so.35(+0x58c85) [0x7f3f7aabcc85]
14 /lib64/libpthread.so.0() [0x3370207a51]
15 clone() in /lib64/libc.so.6

Blitz.log has many occurrences of the this message:
***************************************************************************************
Error connecting to database table dbpatch. You may need to bootstrap.
See http://www.openmicroscopy.org/site/supp ... grade.html
***************************************************************************************

But I don't really understand what that means and the word "bootstrap" does not appear on that page.
As part of the upgrade of Python I did also upgrade psql to 9.4 from the earlier 9.3. Might it be related to that?

Thanks,
- Damir

[atarkowska]

Hi Damir,

did you download server zip again to the new location? if not did you try to delete var/ ?

did you check if postgres is running?

Ola

[dsudar]

Never mind. I answered my own question already. It was an issue with having switched from postgresql 9.3 to 9.4. Apparently that upgrade did not result in making the existing database available to the 9.4 server. I temporarily switched back to 9.3 and it now works fine. So I'll need to dump the DB and restore it into the 9.4 version of postgresql.
Sorry for the false alarm.
- Damir

[dsudar]

Quick followup: what is the recommended way to upgrade the database from 9.3 to 9.4 on Centos 6.7? I installed postgresql 9.4 and it goes into its own separate directory structure not touching any 9.3 stuff. Should I now use pg_upgrade to upgrade the database? Or is it safer to go the pg_dump/pg_restore route?
Thanks,
- Damir

[sbesson]

Hi Damir,

I would expect both upgrade paths to work. Reading through this PostgreSQL forum thread, it looks like you might want to prefer pg_ugrade for production databases. Either way, please make sure the original PostgreSQL data directory is backed up before running upgrades.

Best,
Sebastien