Ubuntu 14.04 Installer fails with remote Packages

[Schroeti]

Hello Fellow People

I Take the risk looking dumb, but google can not help me and i just need a first Test installation of the Suite.

i want to fresh install on Ubuntu 14.04 with the zcs-8.7.0_GA_1659.UBUNTU14_64.20160628202701 tarball

i get this Error from the install.sh exactly before he should start installing. There are no Issues with remote Packages. i updated apt, untared the tarball. Configured hostname and hosts file. As this is an testinstall only there is no dns yet configured. even if i would go with it there is an existing dns server already here. do i really need to set the testserver free to the outside or what am i missing ?

Thank you in advance

Code: Select all

Installing zimbra-core-components  zimbra-ldap-components zimbra-mta-components zimbra-dnscache-components zimbra-snmp-components zimbra-store-components zimbra-apache-components zimbra-spell-components zimbra-memcached zimbra-proxy-components....
ERROR: Unable to install required packages
Fix the issues with remote package installation and rerun the installer

ADDON:

Now i got a little further. i read the install.log.

Code: Select all

After this operation, 804 MB of additional disk space will be used.
Err https://repo.zimbra.com/apt/87/ trusty/zimbra zimbra-base all 1.0.1-1zimbra8.7b1.14.04
  gnutls_handshake() failed: A TLS packet with unexpected length was received.
E: Failed to fetch https://repo.zimbra.com/apt/87/pool/zimbra/z/zimbra-base/zimbra-base_1.0.1-1zimbra8.7b1.14.04_all.deb  gnutls_handshake() failed: A TLS packet with unexpected length was received.

so there seem to be problem with GIT behind a ASA Firewall. So no real Problem from Zimbra. The problem comes from libcurl3-gnutls which should be rebuild against openssl.
https://github.com/xmendez/wfuzz/wiki/PyCurlSSLBug

I really do not want to do this, but i will see how it works out and maybe tell you. If anyone has this same Problem help ist welcome

[gabrieles]

Funny that just some hours ago was writing about not resurrect old threads...
But I've stepped on this problem just a week ago.

Yes, we know, Ubuntu14 is old and should be abandoned and discarded in favor of more modern ZCS/OS.
That's just the point: we have an old U14/ZCS8812 dual server installation that the customer wants to bring to U20/ZCS8815

We'll adopt the standard rolling upgrade, and the first step is to upgrade the frontend (LDAP/MTA/Proxy) from 8812 to 8815.
Download page says that is deprecated and you should move to supported systems and this is what we are doing.
It says even that "If you need help upgrading or have questions, please open a support case. Your Zimbra Support team is here to assist you." but...

But we can't proceed: install.sh fails

So, it seems that you can't do anything on U14.
apt-get update -> fails against https://repo.zimbra.com
install.sh to update -> fails because apt-get update fails
install.sh to make a fresh install -> fails anyway.

Seems that gnutls26 is too old for repo.zimbra.com. Rebuilding against openssl as stated in the linked guide does not works.
We opened a support case to zimbra and seems they are still trying to figure out the problem...

Are you still able to install an old version on an old OS? Seems a stupid question but in these case we NEED to perform a test migration before trying in directly on the production system...
If so how do we migrate away from Ubuntu 14? Staying on zimbra, ovbiously. O356 and GApps are always there, ready to steal another customer...

[Klug]

U14 -> U16 then "./install.sh -s" ?
8.8.12 is available for U16.

But you need to be sure first that U16 can access the repo...

[wentum]

Funny that just some hours ago was writing about not resurrect old threads...
But I've stepped on this problem just a week ago.

Yes, we know, Ubuntu14 is old and should be abandoned and discarded in favor of more modern ZCS/OS.
That's just the point: we have an old U14/ZCS8812 dual server installation that the customer wants to bring to U20/ZCS8815

We'll adopt the standard rolling upgrade, and the first step is to upgrade the frontend (LDAP/MTA/Proxy) from 8812 to 8815.
Download page says that is deprecated and you should move to supported systems and this is what we are doing.
It says even that "If you need help upgrading or have questions, please open a support case. Your Zimbra Support team is here to assist you." but...

But we can't proceed: install.sh fails

So, it seems that you can't do anything on U14.
apt-get update -> fails against https://repo.zimbra.com
install.sh to update -> fails because apt-get update fails
install.sh to make a fresh install -> fails anyway.

Seems that gnutls26 is too old for repo.zimbra.com. Rebuilding against openssl as stated in the linked guide does not works.
We opened a support case to zimbra and seems they are still trying to figure out the problem...

Are you still able to install an old version on an old OS? Seems a stupid question but in these case we NEED to perform a test migration before trying in directly on the production system...
If so how do we migrate away from Ubuntu 14? Staying on zimbra, ovbiously. O356 and GApps are always there, ready to steal another customer...

Hello gabrieles,

did you solve this one?
I'm unfortunately in the same situation now...

Regards
Joerg

[gabrieles]

Hello wentum,
no we did not resolve.
We tested a workaround on a test infrastructure and on a clone of the production environment, but we still did not executed it on the definitive server.
The workaround consisted in upgrading in-place OS and zimbra following this old guide:

https://wiki.zimbra.com/wiki/Ubuntu_Upg ... _.26_above

That was suggested by zimbra support in a relative case

[wentum]

Hello gabrieles,

did some research and development; was more likely try and error
But found a way to move up inplace from 14.04 LTS to 16.04 LTS with zimbra 8.8.15.

Here are, in brief, my steps:

- have a snapshot and/or backup ready if something goes wrong
- create /etc/update-manager/release-upgrades.d/allow-thirdparty.cfg
- put in:

Code: Select all

	[Sources]
	AllowThirdParty=yes

- backup /opt/zimbra/conf/localconfig.xml (keep it somewhere, you'll need it later)
- as zimbra: zmcontrol stop
- as root: mv /etc/init.d/zimbra /etc/init.d/zimbra.NOSTART
- as root: mv /etc/apt/sources.list.d/zimbra.list /etc/apt/sources.list.d/zimbra.list.bak
- as root: apt-get update
- as root: apt-get dist-upgrade
- as root: apt-get autoremove
- as root: init 6
- as root: do-release-upgrade
- question: sysstat remove -> no
- question: restart services -> yes
- question: keep pamd -> yes
- question: delete old packages -> NO!
- init 6
- apt install aptitude (this is my style, you can probably use apt-get as well...)
- mv /etc/apt/sources.list.d/zimbra.list.bak /etc/apt/sources.list.d/zimbra.list
- put in:

Code: Select all

deb     [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra
deb     [arch=amd64] https://repo.zimbra.com/apt/8815 xenial zimbra
deb-src [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra
deb     [arch=amd64] https://repo.zimbra.com/apt/8815-ne xenial zimbra

- as root: aptitude -> push u, U, g, g
- as root: download {your zimbra version} as 16.04
- as root: tar xvzf {your zimbra version}.tar.gz
- sa root: cd {your zimbra version}
- as root: install.sh -> let installer go through installation. When asked to delete /opt/zimbra say NO! (the default). After a while you will get an ldap error, doesn't matter, let it go all the way to the last dialog where it askes you to fill in some zimbra related stuff, e.g. zimbra ldap admin password and so on...do nothing! Leave dialog using q.
- as root: copy your backup of localconfig.xml to /opt/zimbra/conf
- as root: chown zimbra.zimbra /opt/zimbra/conf/localconfig.xml
- as root: apt-get install zimbra-ldap-patch
- as zimbra: zmcontrol start
- as root: mv /etc/init.d/zimbra.NOSTART /etc/init.d/zimbra
- start testing...

One last remark: this was done against a zimbra NE, but i can see no reason why this should't work against OSE...

Regards
Joerg

[SuperBush]

My solution is to use ngnix proxy to access zimbra repos by http protocol
On any other machine (Windows desktop for example) we start ngnix in proxy mode
xxx.xxx.xxx.xxx - the IP address of that computer
my nginx.conf below
------

#user nobody;
worker_processes 1;

#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;

#pid logs/nginx.pid;


events {
worker_connections 1024;
}

http {
include mime.types;
default_type application/octet-stream;

#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';

#access_log logs/access.log main;

sendfile on;
#tcp_nopush on;

#keepalive_timeout 0;
keepalive_timeout 65;

#gzip on;




server {
listen 80;
server_name repo.mydomain.lan;
location / {
proxy_ssl_server_name on;
proxy_pass https://repo.zimbra.com;
}
}
}
---------
On zimbra server we add in /etc/hosts the new repo local ip address
xxx.xxx.xxx.xxx repo.mydomain.lan

Ater that add in apt sources list /etc/apt/sources.list.d new file zimbamirror.list
-----------
deb [arch=amd64] http://repo.mydomain.lan/apt/87 trusty zimbra
deb [arch=amd64] http://repo.mydomain.lan/apt/8815 trusty zimbra
deb-src [arch=amd64] http://repo.mydomain.lan/apt/87 trusty zimbra
-----------

Please note - http:// not https!

apt-get update

and system ready to upgrade Zimbra by standard way via using Zimbra Repository

apt-get redirected to nginx proxy via http and hgnix connects to Zimbra repo by https using new tls