I'm trying to learn how to use sendEmail to send automated emails. This is the command I entered in Windows command prompt:
sendEmail -f myemail#gmail.com -t youremail#gmail.com -m This is a test message. -s smtp.gmail.com:465 -xu myemail#gmail.com -xp mypassword
However, I get the following error:
ERROR => Connection attempt to smtp.gmail.com:465 failed: IO::SOCKET::INET: Bad hostname 'smtp.gmail.com'
After researching this problem online, I ran telnet on smtp.gmail.com, and found that I could not open a connection. I think this is the problem, though I am still unsure what is causing it. What can I do to fix this?
Update /etc/hosts, add a ip address to smtp.gmail.com:
74.125.203.109 smtp.gmail.com
Update /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
IO::SOCKET::INET: IPV6 - Error may also cause such this kind of issues. [check it by typing ifconfig/ipconfig].
If there are multiple IPV6 addresses, then disconnect your network and reconnect it. [eth0 ifdown & eth0 ifup]
Related
As per offical documentation by Openshift , we can get kubadmin password as below:
crc console --credentials
To login as a regular user, run 'oc login -u developer -p developer https://api.crc.testing:6443'.
To login as an admin, run 'oc login -u kubeadmin -p gALwE-jY6p9-poc9U-gRcdu https://api.crc.testing:6443'
However , I can login successfully with developer/developer .kubeadmin will fail with "Login failed (401 Unauthorized)" . Restart CRC muiltiple times . Still not works ... Any idea about this ?
$ oc login -u developer -p developer https://api.crc.testing:6443
Login successful.
You have one project on this server: "demo"
Using project "demo"
$ oc login -u kubeadmin -p gALwE-jY6p9-poc9U-gRcdu https://api.crc.testing:6443
Login failed (401 Unauthorized)
Verify you have provided correct credentials.
Any inputs will be appreciated . Thanks in advance..
You said you restarted CRC. Have you tried deleting and recreating the cluster?
One of the first steps in productionizing a cluster is to remove the kubeadmin account - is it possible that you've done that and the "crc console --credentials" is now only displaying what it used to be?
If you have another admin account try:
$ oc get -n kube-system secret kubeadmin
The step to remove that account (see: https://docs.openshift.com/container-platform/4.9/authentication/remove-kubeadmin.html) is to simply delete that secret. If you've done that at some point in this cluster's history you'll either need to use your other admin accounts in place of kubeadmin, or recreate the CRC instance (crc stop; crc delete; crc setup)
Just in case others are having this issue and the issue persists even after trying crc stop, crc delete, crc cleanup, crc setup, crc start, I was able to sign in as kubeadmin by NOT using the following command after crc start got my CodeReady Container up and running.
eval $(crc oc-env)
Instead, I issue the crc oc-env command. In this example that the output returns /home/john.doe/.crc/bin/oc.
~]$ crc oc-env
export PATH="/home/john.doe/.crc/bin/oc:$PATH"
# Run this command to configure your shell:
# eval $(crc oc-env)
I then list the contents of the /home/john.doe/.crc/bin/oc directory which shows that the /home/john.doe/.crc/bin/oc directory is symbolically linked to the /home/john.doe/.crc/cache/crc_libvirt__amd64/oc file.
~]$ ll /home/john.doe/.crc/bin/oc
lrwxrwxrwx. 1 john.doe john.doe 61 Jun 8 20:27 oc -> /home/john.doe/.crc/cache/crc_libvirt_4.10.12_amd64/oc
And I was then able to sign in using the absolute path to the oc command line tool.
~]$ /home/john.doe/.crc/cache/crc_libvirt_4.10.12_amd64/oc login -u kubeadmin -p 28Fwr-Znmfb-V6ySF-zUu29 https://api.crc.testing:6443
Login successful.
I'm sure I could dig a bit more into this, checking the contents of my users $PATH, but suffice to say, this at least is a work around for me that gets me to be able to sign in as kubeadmin.
I'm experiencing issue with msmtp on my backup server (OpenSUSE 12.2). I'm trying to send email everytime some of my backups fail. For this reason I would like to use msmtp. I have everything setted up. However, even though I see sent items in my "Sent" AND "Inbox" folder in Gmail, I never received single email on my desired Email account. Could anyone help me please? Scripts follow bellow. Please see that recipient is my gmail acc in log even though in text.txt is different.
.msmtprc
account default
host smtp.gmail.com
port 587
protocol smtp
from myemail#gmail.com
tls on
tls_starttls on
#tls_trust_file /etc/ssl/certs/ca-certificates.crt
tls_certcheck off
tls_nocertcheck
auth on
user myemail#gmail.com
password Mypassword
logfile ~/.msmtp
.msmtp
Feb 25 09:44:28 host=smtp.gmail.com tls=on auth=on user=myemail#gmail.com
from=myemail#gmail.com recipients=myemail#gmail.com mailsize=130 smtpstatus=250
smtpmsg='250 2.0.0 OK 1393317868 g1sm73904348eet.6 - gsmtp' exitcode=EX_OK
text.txt
From: Daily backups <myemail#gmail.com>
To: Recipient's Name <hisemail#domain.com>
Subject: Backup report
Sample text
Command for send email
$ cat text.txt | msmtp -a default myemail#gmail.com
Big thank to all of those who will try to help me.
David
This works for me....
account default
host smtp.gmail.com
port 587
logfile /tmp/msmtp.log
tls on
tls_starttls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
auth login
user myemail#gmail.com
password MyPassWord1
from First LastName
account account2
And then from raspberry Pi command line
echo -e "Subject: Test Mail\r\n\r\nThis is a test mail" |msmtp --debug --from=default -t destinationaddress#gmail.com
Mysql client is behaving strangely on one of my servers.
I have my mysql server (ip 10.0.0.190, used to be 172.16.0.190).
I have another server from which I try to connect, which I will refer to as collab.
Bind address is set to 0.0.0.0 server-side, as well as the Grant options for collab.
When I try to connect through mysql-client, here is what I do :
> mysql -u user -p -h mysql.domain
This doesn't work, and after 30s I get this error message :
ERROR 2003 (HY000): Can't connect to MySQL server on 'mysql.domain' (110)
Now the weird thing is that if I do :
> mysql -u user -p -h 10.0.0.190
Everything works correctly. At first, I thought it was a DNS issue, so I tried ping, dig which all answered properly. ie, from client :
> ping mysql.domain
64 bytes from mysql.domain (10.0.0.190): icmp_req=1 ttl=64 time=0.999 ms
So I launched tcpdump on both the server and the client. On the server I get nothing.
On the client :
> tcpdump port 3306
[ ... ]
11:11:41.139499 IP client.domain.49186 > 172.16.0.190.mysql
[ ... ]
As I said, 172.16.0.190 used to be the client's IP before I switched my network. I understand this is where the error comes from, but I can't figure out how to solve it.
Obviously the error comes from the collab but I can't figure out where does it comes from. I've tried to grep '172.16.0' in my /etc on collab in case I had forgotten anything, but nothing came back.
Moreover, when I try to connect from another server using the FQDM, it works.
Anyone has an idea ?
Thanks,
Cheers
H
this may be a DNS cache issue. Try flushing your cache. If you are on windows/osx, look at this: http://docs.cpanel.net/twiki/bin/view/AllDocumentation/ClearingBrowserCache
I'm not sure what has to be done on Linux.
(Flush on CLIENT side, by the way).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I opened a ssh tunnel as described in this post: Zend_Db: How to connect to a MySQL database over SSH tunnel?
But now I don't know what I actually did. Does this command affect anything on the server?
And how do I close this tunnel, because now I can't use my local mysql properly.
I use OSX Lion and the server runs on Ubuntu 11.10.
Assuming you ran this command: ssh -f user#mysql-server.com -L 3306:mysql-server.com:3306 -N as described in the post you linked.
A breakdown of the command:
ssh: that's pretty self-explanatory. Invokes ssh.
-f: (From the man ssh page)
Requests ssh to go to background just before command execution.
This is useful if ssh is going to ask for passwords or
passphrases, but the user wants it in the background.
Essentially, send ssh to background once you've entered any passwords to establish the connection; it gives the shell prompt back to you at localhost rather than logging you in to remote-host.
user#mysql-server.com: the remote server you'd like to log into.
-L 3306:mysql-server.com:3306: This is the interesting bit. -L (from the man ssh page):
[bind_address:]port:host:hostport
Specifies that the given port on the local (client) host is to be
forwarded to the given host and port on the remote side.
So -L 3306:mysql-server.com:3306 binds the local port 3306 to the remote port 3306 on host mysql-server.com.
When you connect to local port 3306, the connection is forwarded over the secure channel to mysql-server.com. The remote host, mysql-server.com then connects to mysql-server.com on port 3306.
-N: don't execute a command. This is useful for "just forwarding ports" (quoting the man page).
Does this command affect anything on the server?
Yes, it establishes a connection between localhost and mysql-server.com on port 3306.
And how do I close this tunnel...
If you've used -f, you'll notice that the ssh process you've opened heads into the background. The nicer method of closing it is to run ps aux | grep 3306, find the pid of the ssh -f ... -L 3306:mysql-server.com:3306 -N, and kill <pid>. (Or maybe kill -9 <pid>; I forget if just kill works). That has the beautiful benefit of not killing all your other ssh connections; if you've got more than one, re-establishing them can be a slight ... pain.
... because now I can't use my local mysql properly.
This is because you've effectively "captured" the local mysql process and forwarded any traffic that attempts to connect to it, off to the remote mysql process. A much nicer solution would be to not use local port 3306 in the port-forward. Use something that's not used, like 33060. (Higher numbers are generally less used; it's pretty common to port-forward a combination like this: "2525->25", "8080->80", "33060->3306" or similar. Makes remembering slightly easier).
So, if you used ssh -f user#mysql-server.com -L 33060:mysql-server.com:3306 -N, you'd then point your Zend connect-to-mysql function to localhost on port 33060, which would connect to mysql-server.com on port 3306. You can obviously still connect to localhost on port 3306, so you can still use the local mysql server.
This will kill all ssh sessions that you have open from the terminal.
sudo killall ssh
Note: adding as answer since comments don't support code blocks.
In my opinion it is better to NOT use -f and instead just background the process as normal with &. That will give you the exact pid you need to kill:
ssh -N -L1234:other:1234 server &
pid=$!
echo "waiting a few seconds to establish tunnel..."
sleep 5
... do yer stuff... launch mysql workbench whatever
echo "killing ssh tunnel $pid"
kill $pid
Or better yet, just create this as a wrapper script:
# backend-tunnel <your cmd line, possibly 'bash'>
ssh -N -L1234:other:1234 server &
pid=$!
echo "waiting a few seconds to establish tunnel..."
sleep 5
"$#"
echo "killing ssh tunnel $pid"
kill $pid
backend-tunnel mysql-workbench
backend-tunnel bash
I have query regarding connecting mysql to comand prompt.
I did:
open cmd prompt
telnet localhost com 3306
I RECEIVED REPLY as---
some instructions mentioning
telnet [-a][-e escape char][-f log file][-1 user][-t term][host [port]]
-a attempt automatic logon. same as -1 option except uses the currently logged on user's name.
-e Escape char to enter telnet client prompt.
and some more...
but is it right?? or i am lost???
kindly help.
do not telnet to your mysql database.
Instead use the mysql command, a UI like db visualizer (they have a pay version and a free version), or the free ui that comes with maria db (a drop in replacement for mysql).
more more info on the mysql command, try running mysql --help or find it in the mysql reference manual
Edit: more info added here.
Telnet is not a "command prompt", it is a communication protocol (check out telnet protocol on wikipedia) and a program (that uses the communication protocol to communicate). You can not connect to mySql with telnet because mySql does not use the telnet protocol for communication.
I have only accessed mySql for jdbc, so I'm not sure how to solve your problem. I know there is a c api interface for mySql as well. Sections "20 Connectors and APIs," and "15 Replication" in the mysql reference might be helpful.