Initializing ldap...failed. (28416) - ubuntu-14.04

I am trying to configure Zimbra on my Linode (ubuntu). It's been more than 12 continuous hours but I am unable to get it configured correctly. I have followed too many guides from internet already. For the last try, I was trying this: Configure Zimbra and as usual the same error occured. This is the error:
Installing Proxy SSL certificate...done.
Initializing ldap...failed. (28416)
ERROR
Configuration failed
Please address the error and re-run /opt/zimbra/libexec/zmsetup.pl to
complete the configuration.
Errors have been logged to /tmp/zmsetup05102015-071817.log
And this is the last few lines of log file:
Sun May 10 07:22:20 2015 done.
Sun May 10 07:22:20 2015 Installing LDAP SSL certificate...
Sun May 10 07:22:20 2015 *** Running as root user: /opt/zimbra/bin/zmcertmgr deploycrt self
** Saving server config key zimbraSSLCertificate...failed.
** Saving server config key zimbraSSLPrivateKey...failed.
** Installing mta certificate and key...done.
** Installing slapd certificate and key...done.
** Installing proxy certificate and key...done.
** Creating pkcs12 file /opt/zimbra/ssl/zimbra/jetty.pkcs12...done.
** Creating keystore file /opt/zimbra/mailboxd/etc/keystore...done.
** Installing CA to /opt/zimbra/conf/ca...done.
Sun May 10 07:22:25 2015 done.
Sun May 10 07:22:25 2015 Installing Proxy SSL certificate...
Sun May 10 07:22:25 2015 *** Running as root user: /opt/zimbra/bin/zmcertmgr deploycrt self
** Saving server config key zimbraSSLCertificate...failed.
** Saving server config key zimbraSSLPrivateKey...failed.
** Installing mta certificate and key...done.
** Installing slapd certificate and key...done.
** Installing proxy certificate and key...done.
** Creating pkcs12 file /opt/zimbra/ssl/zimbra/jetty.pkcs12...done.
** Creating keystore file /opt/zimbra/mailboxd/etc/keystore...done.
** Installing CA to /opt/zimbra/conf/ca...done.
Sun May 10 07:22:30 2015 done.
Sun May 10 07:22:30 2015 checking isEnabled zimbra-ldap
Sun May 10 07:22:30 2015 zimbra-ldap is enabled
Sun May 10 07:22:30 2015 Initializing ldap...
Sun May 10 07:22:30 2015 *** Running as zimbra user: /opt/zimbra/libexec/zmldapinit
Connection refused at /opt/zimbra/libexec/zmldapinit line 138.
Sun May 10 07:23:13 2015 failed. (28416)
Sun May 10 07:23:13 2015
ERROR
I am not sure, what can be wrong or how to fix it. If any of you have ever faced such problem and know the solution, please let me know.
Thanks

Begin by checking the /tmp/zmsetup05102015-071817.log and then do you have any services that could prevent ldap starting? moreover any ports that may already be in use preventing this?

Related

Apache HttpClient4 + OpenJDK11 different behavior on CentOS Linux and Windows with SSL websites

A Java crawler developed on Apache HttpClient works fine on Windows, but throws "Algorithm constraints check failed on signature algorithm: SHA1withRSA" on Linux when crawling sites having certificate signed by Certum. Both ran on the latest openjdk-11. java.security on both OSes are compared and properties like jdk.certpath.disabledAlgorithms and jdk.security.legacyAlgorithms are the same. I even tried to comment all these properties on the Linux, no no success. Linux ca-certs are up to date and Certum is also trusted on java keystore there. Tools like curl and wget can safely download these https sites.
When running openssl s_client -showcerts -connect, it shows that root certum ca certificate uses RSA-SHA1 on these sites:
3 s:C = PL, O = Unizeto Sp. z o.o., CN = Certum CA
i:C = PL, O = Unizeto Sp. z o.o., CN = Certum CA
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1
v:NotBefore: Jun 11 10:46:39 2002 GMT; NotAfter: Jun 11 10:46:39 2027 GMT
-----BEGIN CERTIFICATE-----
MIIDDDCCAfSgAwIBAgIDAQAgMA0GCSqGSIb3DQEBBQUAMD4xCzAJBgNVBAYTAlBM
MRswGQYDVQQKExJVbml6ZXRvIFNwLiB6IG8uby4xEjAQBgNVBAMTCUNlcnR1bSBD
QTAeFw0wMjA2MTExMDQ2MzlaFw0yNzA2MTExMDQ2MzlaMD4xCzAJBgNVBAYTAlBM
MRswGQYDVQQKExJVbml6ZXRvIFNwLiB6IG8uby4xEjAQBgNVBAMTCUNlcnR1bSBD
QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM6xwS7TT3zNJc4YPk/E
jG+AanPIW1H4m9LcuwBcsaD8dQPugfCI7iNS6eYVM42sLQnFdvkrOYCJ5JdLkKWo
ePhzQ3ukYbDYWMzhbGZ+nPMJXlVjhNWo7/OxLjBos8Q82KxujZlakE403Daaj4GI
ULdtlkIJ89eVgw1BS7Bqa/j8D35in2fE7SZfECYPCE/wpFcozo+47UX2bu4lXapu
Ob7kky/ZR6By6/qmW6/KUz/iDsaWVhFu9+lmqSbYf5VT7QqFiLpPKaVCjF62/IUg
AKpoC6EahQGcxEZjgoi2IrHu/qpGWX7PNSzVttpd90gzFFS269lvzs2I1qsb2pY7
HVkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEA
uI3O7+cUus/usESSbLQ5PqKEbq24IXfS1HeCh+YgQYHu4vgRt2PRFze+GXYkHAQa
TOs9qmdvLdTN/mUxcMUbpgIKumB7bVjCmkn+YzILa+M6wKyrO7Do0wlRjBCDxjTg
xSvgGrZgFCdsMneMvLJymM/NzD+5yCRCFNZX/OYmQ6kd5YCQzgNUKD73P9P4Te1q
CjqTE5s7FCMTY5w/0YcneeVMUeMBrYVdGjux1XMQpNPyvG5k9VpWkKjHDkx0Dy5x
O/fIR/RpbxXyEV6DHpx8Uq79AtoSqFlnGNu8cN2bsWntgM6JQEhqDjXKKWYVIZQs
6GAqm4VKQPNriiTsBhYscw==
OpenJDK version on Linux:
OpenJDK Runtime Environment (Red_Hat-11.0.17.0.8-2.el9) (build 11.0.17+8-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-11.0.17.0.8-2.el9) (build 11.0.17+8-LTS, mixed mode, sharing)
Here is the exception trace:
javax.net.ssl.SSLHandshakeException: Certificates do not conform to algorithm constraints
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:353)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:296)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:291)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:654)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:473)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:369)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:183)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1506)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1416)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:456)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:427)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:436)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at myproject.Crawler.load(Crawler.java:127)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints
at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1681)
at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1606)
at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1550)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:638)
... 28 common frames omitted
Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on signature algorithm: SHA1withRSA
at java.base/sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:237)
at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1677)
Seems that CentOS stream 9 overrides Java security policies on /usr/share/crypto-policies/DEFAULT/java.txt (accessible from /etc/crypto-policies/back-ends). Replaced JDK default jdk.certpath.disabledAlgorithms in the file resolved the issue!

Failed to authenticate w/ Google Authenticator when configuring OpenVPN on OpenWRT

I'm quite new to OpenWRT and I'm facing some problems here.
I set up the OpenVPN server on a Ubuntu using OpenVPN Access Server web GUI, and correspondingly I got the client profile client.ovpn. Also I enabled "Google Authenticator Multi-Factor Authentication". When I configured as a client using client.ovpn, it worked perfectly on my phone, my other PC, but it just failed when I tried to start a client on OpenWRT on my router.
According to https://openvpn.net/vpn-server-resources/connecting-to-access-server-with-linux/, I used openvpn --config client.ovpn --auth-user-pass --auth-retry interact to start a connection, and I was prompted for a username and a password, which makes sense, but then I was never prompted for the authenticator code. Actually when I looked at the response, it did ask me for a code, but I never had a place to enter it. Instead, it asked to enter the username again, thus dropping into a loop. See below: (the forth line from the bottom)
root#OpenWrt:/etc/openvpn# openvpn --config client_gui.ovpn --auth-retry interac
t
Mon Mar 9 19:01:18 2020 Unrecognized option or missing or extra parameter(s) in client_gui.ovpn:124: static-challenge (2.4.7)
Mon Mar 9 19:01:18 2020 OpenVPN 2.4.7 mipsel-openwrt-linux-gnu [SSL (mbed TLS)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Mon Mar 9 19:01:18 2020 library versions: mbed TLS 2.16.3, LZO 2.10
Enter Auth Username:london
Enter Auth Password:
Mon Mar 9 19:01:24 2020 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Mon Mar 9 19:01:24 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mon Mar 9 19:01:24 2020 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Mar 9 19:01:24 2020 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Mar 9 19:01:24 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.8.222:1194
Mon Mar 9 19:01:24 2020 Socket Buffers: R=[163840->163840] S=[163840->163840]
Mon Mar 9 19:01:24 2020 UDP link local: (not bound)
Mon Mar 9 19:01:24 2020 UDP link remote: [AF_INET]192.168.8.222:1194
Mon Mar 9 19:01:24 2020 TLS: Initial packet from [AF_INET]192.168.8.222:1194, sid=fb509f08 f4ae8b1f
Mon Mar 9 19:01:24 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Mar 9 19:01:24 2020 VERIFY OK: depth=1, CN=OpenVPN CA
Mon Mar 9 19:01:24 2020 VERIFY OK: nsCertType=SERVER
Mon Mar 9 19:01:24 2020 VERIFY OK: depth=0, CN=OpenVPN Server
Mon Mar 9 19:01:24 2020 Control Channel: TLSv1.2, cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384, 2048 bit key
Mon Mar 9 19:01:24 2020 [OpenVPN Server] Peer Connection Initiated with [AF_INET]192.168.8.222:1194
Mon Mar 9 19:01:25 2020 SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
Mon Mar 9 19:01:25 2020 AUTH: Received control message: AUTH_FAILED,CRV1:R,E:PG_09HT0rZcjdFd6GnA:bG9uZG9u:Enter Authenticator Code
Mon Mar 9 19:01:25 2020 SIGUSR1[soft,auth-failure] received, process restarting
Mon Mar 9 19:01:25 2020 Restart pause, 5 second(s)
Enter Auth Username:
How can I solve this problem? Is there anything to be modified in client.ovpn? Thank you!
In 18.04, Create a file userpass in same directory as client.ovpn.
Userpass should contains 2 lines
username in first line
password in second line
and save the file, open new terminal, Execute the script.
openvpn --config client.ovpn --auth-user-pass userpass --auth-retry interact
In 16.04
Execute the following code
sudo -s
wget -O - https://swupdate.openvpn.net/repos/repo-public.gpg|apt-key add -
echo "deb http://build.openvpn.net/debian/openvpn/stable xenial main" > /etc/apt/sources.list.d/openvpn-aptrepo.list
apt-get update
apt-get dist-upgrade
Create a file userpass in same directory as client.ovpn.
Userpass should contains 2 lines
username in first line
password in second line
and save the file, open new terminal, Execute the script.
openvpn --config client.ovpn --auth-user-pass userpass --auth-retry interact

Servers with same timezone but different time

I have 3 servers, 2 on AWS and one on Digital Ocean, and the timezone for all is set to CDT. But when I check the current time on all 3 by using the date command via command line, none of them matches.
Server1: Wed Jun 12 23:36:01 CDT 2019
Server2: Wed Jun 12 23:45:51 CDT 2019
Server3: Wed Jun 12 23:38:39 CDT 2019
Could anyone please suggest what needs to be done here? Thanks.
Since you have not explicitly said that you have ntp running on them, you'll need to install that. Once that is installed and set up properly, you should show the same exact time on all of them.

GPFS : mmremote: Unable to determine the local node identity

I had a 4 node, gpfs cluster up and running, and things were fine till last week when the Server hosting these RHEL setups went down, After the server was brought up and rhel nodes were started back, one of the nodes's IP got changed,
After that I am not able to use the node,
simple commands like 'mmlscluster', mmgetstate', fails with this error:
[root#gpfs3 ~]# mmlscluster mmlscluster: Unable to determine the local
node identity. mmlscluster: Command failed. Examine previous error
messages to determine cause. [root#gpfs3 ~]# mmstartup mmstartup:
Unable to determine the local node identity. mmstartup: Command
failed. Examine previous error messages to determine cause.
Mmshutdown fails with different error:
[root#gpfs3 ~]# mmshutdown mmshutdown: Unexpected error from
getLocalNodeData: Unknown environmentType . Return code: 1
logs have this info:
Mon Feb 15 18:18:34 IST 2016: Node rebooted. Starting mmautoload...
mmautoload: Unable to determine the local node identity. Mon Feb 15
18:18:34 IST 2016 mmautoload: GPFS is waiting for daemon network
mmautoload: Unable to determine the local node identity. Mon Feb 15
18:19:34 IST 2016 mmautoload: GPFS is waiting for daemon network
mmautoload: Unable to determine the local node identity. Mon Feb 15
18:20:34 IST 2016 mmautoload: GPFS is waiting for daemon network
mmautoload: Unable to determine the local node identity. Mon Feb 15
18:21:35 IST 2016 mmautoload: GPFS is waiting for daemon network
mmautoload: Unable to determine the local node identity. Mon Feb 15
18:22:35 IST 2016 mmautoload: GPFS is waiting for daemon network
mmautoload: Unable to determine the local node identity. mmautoload:
The GPFS environment cannot be initialized. mmautoload: Correct the
problem and use mmstartup to start GPFS.
I tried changing the IP to new one, still the same error:
[root#gpfs1 ~]# mmchnode -N gpfs3 --admin-interface=xx.xx.xx.xx Mon Feb 15 20:00:05 IST 2016:
mmchnode: Processing node gpfs3 mmremote: Unable to determine the
local node identity. mmremote: Command failed. Examine previous error
messages to determine cause. mmremote: Unable to determine the local
node identity. mmremote: Command failed. Examine previous error
messages to determine cause. mmchnode: Unexpected error from
checkExistingClusterNode gpfs3. Return code: 0 mmchnode: Command
failed. Examine previous error messages to determine cause.
Can someone please help me in fixing this issue?
The easiest fix is probably to remove the node from the cluster (mmdelnode) and then add it back in (mmaddnode). You might need to mmdelnode -f.
If deleting and adding the node back in is not an option, try giving IBM support a call.

Apache: Failed to configure CA certificate chain

Pre-note: The certificates was purchased from a vendor and are valid till 2018
Our Apache for one of our servers (Ubuntu 12.04) crashed this morning. Trying to restart Apache kept giving us the following error message
[Wed Jun 03 12:21:51.875811 2015] [ssl:emerg] [pid 30534] AH01903: Failed to configure CA certificate chain!
[Wed Jun 03 12:21:51.875846 2015] [ssl:emerg] [pid 30534] AH02311: Fatal error initialising mod_ssl, exiting. See /var/log/apache2/error.log for more information
After removing the following line from apache config
SSLCertificateChainFile /etc/apache2/ssl/wck.bundle
Apache reloaded.
The server did not restart so I am sure no updates where done by accident.
I then proceeded to try and get it up and running on one of the 14.04 Ubuntu servers we own. The same problem occurred with the same certificates. I asked the guy who setup the 14.04 apache and he claims the problem we suddenly experienced today with the 12.04 server has always happened on the 14.04 server.
I tried reproducing the error on my local 14.04 by installing a new Apache and copying the certificates and one of the config files for one of the sites to my local machine. On my local machine after the setup everything worked perfectly.
I have tried comparing openssl versions, lib version between the two 14.04, but everything looks the same. I even upgraded both my local machine and the 14.04 server to ensure the libs and Apache version are identical, but the one works and the other one doesn't and I recon If I can solve this problem for the 14.04 Ubuntu server it will provide me with the information to get the ssl certificate chain up and running on the 12.04 Machine.
Does anyone have an idea why suddenly the 12.04 Ubuntu's Apache would stop working with the ssl certaficate chain and the 14.04 server also produces the same error, but my local 14.04 does not?
Any help would be appreciated.
Thanks in advance.

Resources