I installed sendmail on both server1 and server2. They use the same configuration file: sendmail.mc. I can send/receive mails to/from the users on the same server using an email client from my PC. But I can not send email to the users on the other server. For example, I can not send an email to bbb#server2domain.com from aaa#server1domain.com using the email client. I've added the ip address of my PC to /etc/mail/access on server1(Connect:zz.zz.zz.zz RELAY) and rebuilt access.db. Looking into /var/log/maillog, sendmail on server1 successfully accepted the mail from the PC but waited for a long time when connecting to server2
Apr 3 07:21:06 server1 sendmail[19771]: v33BKxfr019769: SMTP outgoing connect on server1.xxxxx.com
then timeout:
Apr 3 07:26:06 server1 sendmail[19771]: v33BKxfr019769: timeout waiting for input from server2domain.com. during client greeting
Apr 3 07:26:06 server1 sendmail[19771]: v33BKxfr019769: to=, ctladdr= (501/501), delay=00:05:04, xdelay=00:05:00, mailer=esmtp, pri=121178, relay=server2domain.com. [yy.yy.yy.yy], dsn=4.0.0, stat=Deferred: Connection timed out with server2domain.com.
On server2, the log is:
Apr 3 07:18:02 server2 sendmail[20121]: v33BI2Os020121: assigned id
Apr 3 07:18:02 server2 sendmail[20121]: NOQUEUE: connect from [xx.xx.xx.xx]
Apr 3 07:18:02 server2 sendmail[20121]: AUTH: available mech=ANONYMOUS,
allowed mech=EXTERNAL GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5
Apr 3 07:18:02 server2 sendmail[20121]: v33BI2Os020121: Milter: no active filter
Apr 3 07:23:02 server2 sendmail[20121]: STARTTLS=server, info: fds=6/4, err=5
Apr 3 07:23:02 server2 sendmail[20121]: STARTTLS=server, error: accept failed=0, SSL_error=5, errno=0, retry=-1, relay=[xx.xx.xx.xx]
Apr 3 07:23:02 server2 sendmail[20121]: v33BI2Os020121: disconnect level 1
Apr 3 07:23:02 server2 sendmail[20121]: v33BI2Os020121: in background, pid=20121
Apr 3 07:23:02 server2 sendmail[20121]: v33BI2Os020121: [xx.xx.xx.xx] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-SSL
I can successfully send email to server2 on server1 using the openssl command and do not need to input user name/password.
The sendmail.mc is:
divert(-1)dnl
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for linux')dnl
OSTYPE(`linux')dnl
define(`confDEF_USER_ID', ``8:12'')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST', `True')dnl
define(`confDONT_PROBE_INTERFACES', `True')dnl
define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`STATUS_FILE', `/var/log/mail/statistics')dnl
define(`UUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A')dnl
define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl
define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.crt')dnl
define(`confSERVER_CERT', `/etc/pki/tls/certs/sendmail.pem')dnl
define(`confSERVER_KEY', `/etc/pki/tls/certs/sendmail.pem')dnl
define(`confCRL', `/etc/pki/tls/certs/revoke.crl')
define(`confCLIENT_CERT', `/etc/pki/tls/certs/sendmail.pem')
define(`confCLIENT_KEY', `/etc/pki/tls/certs/sendmail.pem')
define(`confTO_IDENT', `0')dnl
FEATURE(`no_default_msa', `dnl')dnl
FEATURE(`smrsh', `/usr/sbin/smrsh')dnl
FEATURE(`mailertable', `hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
FEATURE(local_procmail, `', `procmail -t -Y -a $h -d $u')dnl
FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
DAEMON_OPTIONS(`Family=inet, Port=465, Name=MTA-SSL, M=s')dnl
CLIENT_OPTIONS(`Family=inet')dnl
FEATURE(`accept_unresolvable_domains')dnl
LOCAL_DOMAIN(`localhost.localdomain')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 465')
define(`ESMTP_MAILER_ARGS', `TCP $h 465')
MAILER(smtp)dnl
MAILER(procmail)dnl
Both sendmail listen on port 465. I doubt the problem is related to auth but do not know the reason.
Please help, thank you!
After adopting Andrzej A. Filip's suggestion and removing the two lines in sendmail.mc, the following error occurs in the log on server1:
Apr 3 13:02:25 server sendmail[19927]: v33BKxfr019769: makeconnection (server2domain.com. [yy.yy.yy.yy]) failed: Connection refused by server2domain.com.
Apr 3 13:02:25 server sendmail[19927]: v33BKxfr019769: makeconnection (server2domain.com. [yy.yy.yy.yy]) failed: Connection refused by server2domain.com.
Apr 3 13:02:25 server sendmail[19927]: v33BKxfr019769: to=, ctladdr= (501/501), delay=05:41:23, xdelay=00:00:01, mailer=esmtp, pri=301178, relay=server2domain.com. [yy.yy.yy.yy], dsn=4.0.0, stat=Deferred: Connection refused by server2domain.com.
There is no message logged on server2.
I think without the two lines, sendmail on server1 will try to connect the server2 via port 25, not the port 465 that sendmail is listening.
sendmail and OUTGOING smtps (465) connections
smtps (465) starts SSL session before any SMTP level communications. AFAIR sendmail does not support it natively for outgoing connections.
Remove the following two lines, recompile your sendmail.mc into sendmail.cf, restart or (send signal) HUP your sendmail daemon.
define(`RELAY_MAILER_ARGS', `TCP $h 465')
define(`ESMTP_MAILER_ARGS', `TCP $h 465')
Related
I compiled qemu-system-x86_64 on aarch64 host, and was able to run a x86_64 guest with a command like
qemu-system-x86_64 -m 4096 -drive file=vmimage.qcow2,if=virtio \
-boot once=c,menu=on -net nic,model=virtio-net-pci \
-net user,hostfwd=tcp::8080-:80,hostfwd=tcp::22222-:22
I could ssh into the guest using
ssh -p22222 user#localhost
Meanwhile, port 80 was not forwarded successfully.
For debugging, I used nc to listen to port 80 inside the guest
nc -l 80
Then in the host, I connected to the forwarded port
nc localhost 8080
However, it was unable to connect to guest nc .
I tried the monitor interface. When the host nc command is executed, info usernet shows following:
(qemu) info usernet
Hub 0 (#net162):
Protocol[State] FD Source Address Port Dest. Address Port RecvQ SendQ
TCP[SYN_SENT] 33 127.0.0.1 8080 10.0.2.15 80 0 0
TCP[ESTABLISHED] 21 127.0.0.1 22222 10.0.2.15 22 0 0
TCP[HOST_FORWARD] 12 * 8080 10.0.2.15 80 0 0
TCP[HOST_FORWARD] 11 * 22222 10.0.2.15 22 0 0
...
I believe the SYN_SENT (FD 33) corresponded to the host nc command, and this matched the HOST_FORWARD line (FD 12). However, it never became ESTABLISHED. And a few seconds later, nc died with Connection reset by peer. , and the FD 33 line disappeared.
If I nc localhost 22222, I can see the OpenSSH banner.
So it seems only port 22 forwarded. Any idea about the cause or how to debug?
Both host and guest had no firewalliptables configured, and SELinux is permissive.
Thanks
Edit:
As a temporary workaround, I configured a second nic, and used port 22 of the new interface for forwarding my service. I also switch to the newer -nic option, but hostfwd still worked for port 22 only.
qemu-system-x86_64 -m 4096 -drive file=vmimage.qcow2,if=virtio \
-boot once=c,menu=on \
-nic user,model=virtio-net-pci,hostfwd=tcp::60022-:22 \
-nic user,model=virtio-net-pci,net=10.0.3.0/24,hostfwd=tcp::8080-10.0.3.15:22
To forward successfully, I also need to
Configure sshd to listen to port 22 the first nic only.
Configure my service to listen to port 22 of the second nic.
Configure the second nic to use a different network. Otherwise, both nics were assigned the same IP (10.0.2.15. I may better hardcode the IP for both nics.)
The problem was actually about firewall. My VM (based on Oracle Linux 8.5 on Oracle Linux VM Templates) actually had firewall rules in both iptables and nft. After disabling both iptables and nft, the port forward worked.
Openshift 4.4.17 cluster (3 masters and 3 workers).
Getting error when trying to see logs (or exec terminal) on those pods running on worker nodes. The same applies for Openshift GUI. No issues when trying to do the same for pods running on master nodes.
Example 1: pods running on worker
$ oc whoami
kube:admin
$ oc get pod -n lamp
NAME READY STATUS RESTARTS AGE
lamp-lamp-6c7d9f467d-jsn4t 3/3 Running 0 108d
$ oc logs lamp-lamp-6c7d9f467d-jsn4t httpd -n lamp
error: You must be logged in to the server (the server has asked for the client to provide credentials ( pods/log lamp-lamp-6c7d9f467d-jsn4t))
Example 2: pods running on master nodes
$ oc get pod -n openshift-apiserver
NAME READY STATUS RESTARTS AGE
apiserver-6d64545f-5lmb8 1/1 Running 0 2d19h
apiserver-6d64545f-hktqd 1/1 Running 0 2d19h
apiserver-6d64545f-kb4qt 1/1 Running 0 2d19h
$ oc logs apiserver-6d64545f-5lmb8 -n openshift-apiserver
Copying system trust bundle
I0225 20:41:39.989689 1 requestheader_controller.go:243] (..output omitted..)
Investigating kubelet on worker nodes:
On every worker node kubelet service is running, but
journalctl -u kubelet
shows these two lines:
Unable to authenticate the request due to an error: x509: certificate signed by unknown authority
logging error output: "Unauthorized"
About kubeconfig on worker nodes:
Watching the content of /etc/kubernetes/kubeconfig file.
- kubelet connects to api-server --> https://api-int.ocs-cls1.mycompany.lab
- the server passes valid certificate signed by --> kube-apiserver-lb-signer
- certificate-authority-data carries --> kube-apiserver-lb-signer rootCA
The kubeconfig looks like correct.
UPDATE:
Also noticed these log lines reporting bad certificate:
$ oc -n openshift-apiserver logs apiserver-6d64545f-5lmb8
log.go:172] http: TLS handshake error from 10.128.0.12:47078: remote error: tls: bad certificate
...
UPDATE2:
Also checked apiserver-loopback-client certificate:
$ curl --resolve apiserver-loopback-client:6443:{IP_MASTER} -v -k https://apiserver-loopback-client:6443/healthz
server certificate verification SKIPPED
* server certificate status verification SKIPPED
* common name: apiserver-loopback-client#1614330374 (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: CN=apiserver-loopback-client#1614330374
* start date: Fri, 26 Feb 2021 08:06:13 GMT
* expire date: Sat, 26 Feb 2022 08:06:13 GMT
* issuer: CN=apiserver-loopback-client-ca#1614330374
try this
while :;do
sleep 2
oc get csr -o name | xargs -r oc adm certificate approve
done
use the another terminal, and ssh to the any master node, run this:
crictl ps -a | awk '/Running/&&/-cert-syncer/{print $1}' | xargs -r crictl stop
When trying to persist an entity from Cygnus to Cosmos global instance it fails.
Looking at the log file I see something like that:
2015 15:31:50,006 DEBUG [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.http.impl.conn.DefaultClientConnection.sendRequestHeader:273) - >> GET /webhdfs/v1/user/ms/def_serv/def_servpath/6_registervalues/6_registervalues.txt?op=getfilestatus&user.name=ms HTTP/1.1
12 Nov 2015 15:31:50,006 DEBUG [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.http.impl.conn.DefaultClientConnection.sendRequestHeader:276) - >> X-Auth-Token: xxxxxxxxxxxxxxxxxxx
12 Nov 2015 15:31:50,006 DEBUG [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.http.impl.conn.DefaultClientConnection.sendRequestHeader:276) - >> Host: cosmos.lab.fiware.org:14000
12 Nov 2015 15:31:50,006 DEBUG [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.http.impl.conn.DefaultClientConnection.sendRequestHeader:276) - >> Connection: Keep-Alive
12 Nov 2015 15:31:50,007 DEBUG [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.http.impl.conn.DefaultClientConnection.sendRequestHeader:276) - >> User-Agent: Apache-HttpClient/4.2.1 (java 1.5)
12 Nov 2015 15:31:50,284 DEBUG [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.http.impl.conn.DefaultClientConnection.close:169) - Connection 0.0.0.0:59834<->130.206.80.46:14000 closed
12 Nov 2015 15:31:50,285 DEBUG [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.http.impl.client.DefaultRequestDirector.tryExecute:716) - Closing the connection.
12 Nov 2015 15:31:50,285 DEBUG [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.http.impl.conn.DefaultClientConnection.close:169) - Connection 0.0.0.0:59834<->130.206.80.46:14000 closed
12 Nov 2015 15:31:50,286 INFO [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.http.impl.client.DefaultRequestDirector.tryExecute:723) - I/O exception (java.net.SocketException) caught when processing request: Connection reset
12 Nov 2015 15:31:50,287 DEBUG [SinkRunner-PollingRunner-DefaultSinkProcessor] (org.apache.http.impl.client.DefaultRequestDirector.tryExecute:728) - Connection reset
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:185)
at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
(I have obfuscated the token in the example above.)
for some reason the connection is closed.
Orion and Cygnus are installed on a fiware lab private instance in Spain2.
When trying to fire the same request from the command line from the Orion machine, I get the same disconnected response.
curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/ms/def_serv/def_servpath/6_registervalues/6_registervalues.txt?op=getfilestatus&user.name=ms" -H "X-Auth-Token: xxxxxxxxxxxxxxxxxxxxxx"
curl: (56) Failure when receiving data from the peer
But surprisingly, when doing the same request from the command line from the Cosmos global instance, it works!
See:
[ms#cosmosmaster-gi ~]$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/ms/def_serv/def_servpath/6_registervalues/6_registervalues.txt?op=getfilestatus&user.name=ms" -H "X-Auth-Token: xxxxxxxxxxxxxxxxx"
{"FileStatus":{"pathSuffix":"","type":"FILE","length":2,"owner":"ms","group":"ms","permission":"644","accessTime":1447332222908,"modificationTime":1447253745711,"blockSize":67108864,"replication":3}}
[ms#cosmosmaster-gi ~]$
Seems like Cosmos will not service connection arriving from a fiware lab instance running on Spain2.
Does anyone knows what's the issue here, and how to correct this.
Thanks!
Menachem S.
Issue was solved by a workaround.
The Cygnus server was installed on an external node ( a Machine on Azure), and everything works fine wrt Orion-->Cygnus-->Cosmos stream.
I've installed Orion Context Broker 0.23.0 and it behaves rare: it only works half of the times. For instance, when trying to retrieve the version I get this error message:
$ curl "http://localhost:1026/version"
curl: (52) Empty reply from server
$ curl "http://localhost:1026/version"
<orion>
<version>0.23.0</version>
<uptime>15 d, 22 h, 13 m, 18 s</uptime>
<git_hash>f5d76a6f11736d52402e63a4aa0ba990bff7f5eb</git_hash>
<compile_time>Fri Jul 10 13:21:42 CEST 2015</compile_time>
<compiled_by>fermin</compiled_by>
<compiled_in>centollo</compiled_in>
</orion>
$ curl "http://localhost:1026/version"
curl: (52) Empty reply from server
$ curl "http://localhost:1026/version"
<orion>
<version>0.23.0</version>
<uptime>15 d, 22 h, 13 m, 53 s</uptime>
<git_hash>f5d76a6f11736d52402e63a4aa0ba990bff7f5eb</git_hash>
<compile_time>Fri Jul 10 13:21:42 CEST 2015</compile_time>
<compiled_by>fermin</compiled_by>
<compiled_in>centollo</compiled_in>
</orion>
This behaviour is deterministic, I mean, after failing it always works, and after working it always fails. This occurs with all the operations within the REST API.
I've checked the listening ports and the process running them matches the Orion's one:
$ sudo netstat -ntlp | grep 1026
tcp 0 0 0.0.0.0:1026 0.0.0.0:* LISTEN 9944/contextBroker
tcp 0 0 :::1026 :::* LISTEN 9944/contextBroker
$ ps ax | grep contextBroker | grep -v grep
9944 ? Ssl 0:13 /usr/bin/contextBroker -port 1026 -logDir /var/log/contextBroker -pidpath /var/run/contextBroker/contextBroker.pid -dbhost localhost -db orion -multiservice
Any hints? Thanks!
Orion runs by default listening to IPv4 and IPv6. We have found that in cases similar to the ones you described disabling IPv6 solves the problem (we don't know yet the exact cause, maybe is related with the operating system or it is involved is some way...).
Tu run Orion in only-IPv4 mode you have to use the -ipv4 option either in the contextBroker command line or (if you are running Orion as a service) editing the /etc/sysconfig/contextBroker file to add -ipv4 to the BROKER_EXTRA_OPS variable (have a look to the documentation for more information about configuring Orion as a service). After modifying /etc/sysconfig/contextBroker you have to restart Orion using:
sudo /etc/init.d/contextBroker restart
I am trying to connect dovecot on 993 port but dovecot shows below error;
dovecot: imap-login: Disconnected (no auth attempts in 60 secs): user=<>, rip=192.***.***.***, lip=192.***.***.***, TLS handshaking: SSL_accept() failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol, session=<3k6jgTwVLwDAqL+E>
squirrelmail config;
$imap_auth_mech = 'login';
$use_imap_tls = 1;
$imapServerAddress = 'dovecot.server';
$imapPort = 993;
When I try to telnet and openssl on squirrelmail server;
[root#aa ~]# telnet dovecot.server 993
Trying 192.***.***.***...
Connected to dovecot.server.
Escape character is '^]'.
[root#aa ~]# openssl s_client -connect dovecot.server:993
...
...
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
Note: 143 port works fine by the way.
Check your PHP error log for things like this:
PHP Warning: fsockopen(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed ..
PHP Warning: fsockopen(): Failed to enable crypto ..
PHP Warning: fsockopen(): unable to connect to tls://dovecot.server:993 (Unknown error) ..
If that's the case, the openssl library isn't able to verify your server's cert. It's easily fixed by adding the certificate for the connection to your local cert stash. You can find out where that is with <PRE><?php var_dump(openssl_get_cert_locations()); ?> </pre> and looking at the ini_cafile setting.
You can get your server's cert with this command:
openssl x509 -in <(openssl s_client -connect dovecot.server:993 -prexit 2>/dev/null) > /tmp/cacert.pem
Add it to the cert file, and you should be going.
One caveat: the certificate CN MUST match the hostname that you're using to connect to the server! If it's self-signed, make sure it's using dovecot.server as the CN.