I just reran the upgrade and instead of running some migration code (like when I went from 301-160 to 310-279) it looked like a new install. It seems to be running ok though.Originally Posted by KevinH
LinkBack URL
About LinkBacks
Senior Member
I just reran the upgrade and instead of running some migration code (like when I went from 301-160 to 310-279) it looked like a new install. It seems to be running ok though.
Active Member
New problems now with LDAP
Well, I just tried twice and was unsuccessful. This time, it looks like its not able to get as far as it did originally.
I went through the ./install.sh again and it removes all rpms, then installs the new ones, sets defaults from saved config in /opt/zimbra/.saveconfig/config.save, checks port conflicts, says it started ldap... Done, then attempts to set defaults from ldap and then gets this error:
After that, the "Checking ldap on localhost:389" will fail too and it will then go to this:Code:Starting ldap...Done Setting defaults from ldap...ERROR: service.FAILURE (system failure: unable to lookup server by name: hail.networkpenguin.com) (cause: javax.naming.NamingException [LDAP: error code 80 - internal error]) ERROR: service.FAILURE (system failure: unable to lookup server by name: hail.networkpenguin.com) (cause: javax.naming.NamingException [LDAP: error code 80 - internal error]) ERROR: service.FAILURE (system failure: unable to lookup server by name: hail.networkpenguin.com) (cause: javax.naming.NamingException [LDAP: error code 80 - internal error]) ERROR: service.FAILURE (system failure: unable to lookup server by name: hail.networkpenguin.com) (cause: javax.naming.NamingException [LDAP: error code 80 - internal error]) ERROR: service.FAILURE (system failure: unable to lookup server by name: hail.networkpenguin.com) (cause: javax.naming.NamingException [LDAP: error code 80 - internal error]) Done Checking ldap on localhost:389...
II attempt to fix "Web server HTTP port" and the HTTPS one, because I previously changed them from the defaults using zmprov, I believe. But even with those set, it seems like its having ldap issues.Code:Checking ldap on localhost:389...FAILED ( ldap_result: Can't contact LDAP server (-1) # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (objectclass=*) # requesting: ALL # ) Checking ldap on localhost:389...FAILED ( ldap_bind: Can't contact LDAP server (-1) ) Main menu 1) Hostname: hail.networkpenguin.com 2) Ldap master host: hail.networkpenguin.com 3) Ldap port: 389 4) Ldap password: set 5) zimbra-ldap: Enabled 6) zimbra-store: Enabled +Create Admin User: no +SMTP host: hail.networkpenguin.com ******* +Web server HTTP port: UNSET ******* +Web server HTTPS port: UNSET +Web server mode: mixed +IMAP server port: 143 +IMAP server SSL port: 993 +POP server port: 110 +POP server SSL port: 995 +Use spell check server: yes +Spell server URL: http://hail.networkpenguin.com:7780/aspell.php 7) zimbra-mta: Enabled 8) zimbra-snmp: Enabled 9) zimbra-logger: Enabled 10) zimbra-spell: Enabled r) Start servers after configuration yes s) Save config to file x) Expand menu q) Quit Address unconfigured (**) items or correct ldap configuration (? - help)
Zimbra Employee
This seems pretty unambigous:
host hail.networkpenguin.comSetting defaults from ldap...ERROR: service.FAILURE (system failure: unable to lookup server by name: hail.networkpenguin.com) (cause:
hail.networkpenguin.com has address 192.168.200.11
I can look up your host by name (private IP space in public DNS? Shame on you- what's in this host's /etc/resolv.conf that prevents it from resolving it's own name?
Active Member
Yep. I did that to attempt to fool postfix at one point because I couldn't remember how to force it to not lookup MX's and instead use itself. 3.0 has been running on this box for the last few months. I have rebooted it a few times and have not done updates recently on this system. So as soon as I finish upgrading Zimbra, I'll do some yum updates. But nothing has change until today when I tried upgrading.
the hosts
and the resolv.confCode:[root@hail ~]# cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost 192.168.200.11 hail.networkpenguin.com hail
Code:[root@hail ~]# cat /etc/resolv.conf search networkpenguin.com nameserver 4.2.2.1 nameserver 4.2.2.2 nameserver 68.168.224.162 [root@hail ~]# pign hail [root@hail ~]# ping hail.networkpenguin.com PING hail.networkpenguin.com (192.168.200.11) 56(84) bytes of data. 64 bytes from hail.networkpenguin.com (192.168.200.11): icmp_seq=0 ttl=64 time=6.62 ms 64 bytes from hail.networkpenguin.com (192.168.200.11): icmp_seq=1 ttl=64 time=0.208 ms
Zimbra Employee
Postfix isn't the problem - ldap is - and /etc/hosts isn't the problem - DNS is. Ping is not a valid test, since it'll use the hosts file - run the host command (host `hostname`).
So, you need to make sure that ldap can resolve your hostname via DNS, or this won't work.
(FWIW, when I resolved it I got the info from a 69.x.x.x address)
Active Member
I realize that postfix isn't the issue. I was just mentioning why I have hail.networkpenguin.com registered in my dns. It was my understanding that when your /etc/nsswitch.conf's hosts: entry is set to "files dns" that any stuff that I put in /etc/hosts will be used, when being queried, before dns. I'm not as clear as to HOW ldap queries things. So if it uses another method of name resolution and is capable of bypassing /etc/hosts, things should still work from that system. Here is my query using dig. In addition to 4.2.2.1, I tried my other nameserver entries as well. I'm not sure how you queried hail.networkpenguin.com. Because it should resolve to a 192.etc..etc.. the domain networkpenguin.com will probably resolve the 69.x.x.x.
It seems to me that if this system was working properly before the attempted upgrade, that any DNS resolution issues should have caused probably previously as well-- and they didn't. Could it have been an openldap upgrade issue? What about the schema? Could something be bunged in my schema that would cause some sort of lookup issues? When it says "Setting defaults from ldap..." could that program be attempting to talk with openldap.. and maybe openldap wasn't able to start for some reasons?Code:[root@hail ~]# dig @4.2.2.1 hail.networkpenguin.com ; <<>> DiG 9.3.1 <<>> @4.2.2.1 hail.networkpenguin.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32507 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;hail.networkpenguin.com. IN A ;; ANSWER SECTION: hail.networkpenguin.com. 43118 IN A 192.168.200.11 ;; Query time: 87 msec ;; SERVER: 4.2.2.1#53(4.2.2.1) ;; WHEN: Fri Apr 14 13:12:55 2006 ;; MSG SIZE rcvd: 57
Last edited by hootjr29; 04-14-2006 at 10:26 AM.
Zimbra Employee
Active Member
I don't see it running:
Code:[root@hail zcs]# netstat -an | grep 389 [root@hail zcs]#
Active Member
Question about the install.sh script. Originally the script kicks off and says "Saving existing configuration file to /opt/zimbra/.saveconfig" When it does this and my upgrade fails halfway through ( basically, packages were uninstalled, then new packages were installed, then configs are imported, etc..etc.. ), then I go and rerun the install.sh script and it says "Saving existing configuration file to /opt/zimbra/.saveconfig" again, I would assume that this means it was saving my failed configuration.
Could that having anything to do with ldap not starting correctly and thus preventing the who thing from working correctly?
Active Member
Here's another post that might relate to this ldap issue:
Interupted 3.0 -> 3.1 upgrade
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
