I have set up Hudson but I am having difficulties, getting it to send mails, I have provided an smtp server (the gmail smtp server) but if I do tests, I get this error.
Failed to send out e-mail
com.sun.mail.smtp.SMTPSendFailedException: 530 5.7.0 Must issue a STARTTLS command first.
I have seen some discussions on this in the forum when enabling tls through the command.
$ java -Dmail.smtp.starttls.enable="true" -jar hudson.war
How can you set tls to start if you are using hudson in tomcat? Is there some configuration file you can use?
set your JAVA_OPTS to -Dmail.smtp.starttls.enable=true before starting your tomcat, if you're on unix you can just add
JAVA_OPTS="-Dmail.smtp.starttls.enable=true"
to your $TOMCAT_HOME/bin/catalina.sh (somewhere at the top). On Windows I would set this in the cmdline-Environment.
Related
I have a server running Ovirt Node that I'm trying to manage remotely using libvirt. I have an SSH keypair installed and can ssh user#server -i ssh-privkey successfully. When I try to connect to qemu+ssh//user#host/system?keyfile=ssh-privkey, I get this error:
authentication failed: Failed to start SASL negotiation: -4 (SASL(-4): no mechanism available: No worthy mechs found)
That led me down the path of getting TLS keys and certificates installed on the client and the server mostly according to these instructions (the configuration is slightly different because I have only one host and am using Terraform to manage the certificates*). However, I still get the same error. When I look at the output of libvirt --listen --verbose on the server when a connection failed, the only useful output is this:
error : virNetSocketReadWire:1792 : End of file while reading data: Input/output error
I have checked every firewall between the client and the server and they should all be wide open. What else could be the cause of this error?
* The goal is ultimately to use Terraform to provision libvirt resources, however I get the same errors trying to connect with virsh and virt-manager.
UPDATE: It's easier to connect just via SSH; this question exists because I couldn't figure out how to turn off SASL. It turns out SASL is enabled for SSH connections due to vdsm setting auth_unix_rw="sasl" in /etc/libvirt/libvirtd.conf. Removing that config means I can just use my SSH private key as I intended. The TLS configuration was a wild goose chase that was further hindered by vdsm changing the configured location of all the PKI files.
You're likely missing a RPM package on your client host. First on the virtualization host check /etc/sasl2/libvirt.conf and see what 'mech_list' setting is uncommented.
Back on your client you'll need to install a 'cyrus-sasl-XXXX' RPM that provides the same mechanism that the server is set to use. For a modern libvirt install it will probably be using 'cyrus-sasl-scram' for plain username/password auth, but for older installs, it might still be using 'cyrus-sasl-md5'
I have my MySQL instance configured to use TLS. I have verified this by intentionally using untrusted certificates and watching the clients fail to connect (with an appropriate error message) and then restarting the MySQL service with trusted certificates configured and having the clients connect successfully.
I wanted to do a final check using openssl's s_client but I can't get it to work. When I execute the command below, I get an error saying "SSL23_GET_SERVER_Hello:unknown protocol" followed by "no peer certificate available" followed by some more text. However, when I use the same command against a TLS-enabled Tomcat instance and against the Remote Desktop port, I am able to establish the connection and view the server's certificate. What am I doing wrong? Does MySQL do some extra pre-negotiation before the TLS handshake starts?
openssl s_client -showcerts -connect host:port
While MySQL may use TLS, it isn't the total outside layer. There is a small amount of preamble that occurs before TLS starts. The openssl command line isn't aware of this.
Use the mysql client with its TLS options to test the client certificate.
I marked the response from #danblack correct as he did answer the question. However, I want to provide more information in case it helps anyone else. The
small amount of preamble that occurs before TLS starts
that he refers to can be found on GitHub here.
I am using Bluemix container service and am unable to do cf ic login from behind a firewall, even though I have configured proxies.
When I do
cf ic -v login
I get the error message:
Authenticating with the IBM Containers registry host
registry.ng.bluemix.net... FAILED The attempt to authenticate with the
IBM Containers registry host registry.ng.bluemix.net was unsuccessful.
****Warning: '-e' is deprecated, it will be removed soon. See usage. Error response from daemon: Get
https://registry.ng.bluemix.net/v1/users/: dial tcp
198.23.117.106:443: i/o timeout
To test that my proxy is configured, I do this:
wget https://registry.ng.bluemix.net/v1/users/
--2016-10-25 11:25:23-- https://registry.ng.bluemix.net/v1/users/ Resolving proxy-chain.intel.com (proxy-chain.intel.com)... 10.19.8.225
Connecting to proxy-chain.intel.com
(proxy-chain.intel.com)|10.19.8.225|:912... connected. Proxy request
sent, awaiting response... 404 Not Found 2016-10-25 11:25:24 ERROR
404: Not Found.
If I disconnect VPN so I no longer have a firewall and need a proxy, and unset my proxies, it works.
These are the proxies I have set:
printenv | grep -i proxy
http_proxy=http://proxy-chain.intel.com:911
ftp_proxy=http://proxy-chain.intel.com:911
socks_proxy=http://proxy-chain.intel.com:1080
https_proxy=http://proxy-chain.intel.com:912
no_proxy=intel.com,.intel.com,10.0.0.0/8,192.168.0.0/16,localhost,127.0.0.0/8,134.134.0.0/16
>
More experiments:
When I set the proxy to something bogus, it fails immediately:
> export https_proxy=http://foobarsfsdf.com
> cf ic login
FAILED
auth request failed: Error performing request: Post https://login.ng.bluemix.net/UAALoginServerWAR/oauth/token: http: error connecting to proxy http://foobarsfsdf.com: dial tcp: lookup foobarsfsdf.com on 10.0.2.3:53: no such host
>
When I set the proxy correctly, it fails later:
> cf ic login
Deleting old configuration file...
Retrieving client certificates for IBM Containers...
Storing client certificates in /home/rscohn1/.ice/certs/...
Storing client certificates in /home/rscohn1/.ice/certs/containers-api.ng.bluemix.net/80cc2e8c-4df0-4700-bd04-77f2e8777f80...
OK
The client certificates were retrieved.
Checking local Docker configuration...
OK
Authenticating with the IBM Containers registry host registry.ng.bluemix.net...
FAILED
The attempt to authenticate with the IBM Containers registry host registry.ng.bluemix.net was unsuccessful.
****Warning: '-e' is deprecated, it will be removed soon. See usage.
Error response from daemon: Get https://registry.ng.bluemix.net/v1/users/: dial tcp 198.23.117.106:443: i/o timeout
When you are not connected to the IBM Containers registry host, you can run only a limited number of IBM Containers commands. Check the spelling of the host URL and try again. If the host URL is correct, open a new command line or terminal window before retrying.
It looks like some parts of the ic plugin uses proxies, and some parts do not.
You need to add the proxy on to your Docker daemon configuration. Also note that as Alex says, you should make sure to configure a HTTPS proxy.
See here for some information on how to do that with Systemd on Linux (Ubuntu 16.04+): https://docs.docker.com/engine/admin/systemd/#http-proxy
For older Linux distributions, such as Ubuntu versions before 16.04, Docker uses Upstart. You'll find the Upstart configuration file at /etc/default/docker, with a sample of how to set the proxy up in comments inside that file.
If you're using the Docker for Mac or Docker for Windows apps, you'll find the proxy configuration options in Preferences -> Advanced.
Make sure to restart Docker after changing the configuration, so that your changes take effect. On Linux: sudo service docker restart. On Mac or Windows, right-click the Docker icon and click restart.
This might be a very simple question for those who are running Mule on linux. I have developed Mule ESB 3.3 app on a windows 8 machine and tested to get desired results by calling my app at
http://localhost:8081/myFlowPath
Now I have deployed same app on to a linux machine behind a firewall successfully but am unable to hit it at http://linuxDomainname.com:8081/myFlowPath. The connection is refused. Am I missing something in configuring mule to run on linux?
We are running Mule CE 3.3 standalone as a linux demon. Do I have to explicitly specify something like the port or hostname in the wrapper.conf? Please let me know. Any help is highly appreciated.
Thanks,
Jenni
You have to configure HTTP Listener host to 0.0.0.0 (change from localhost).
Check log mule at HOME_MULE/logs/mule.log or webservice.log
After deploy your app you must have in HOME_MULE/apps/nameofyourapp/webservice.xml (or filename defined in "config.resources" in file mule-deploy.properties) this:
It work for me. I deploying my mule apps on Ubuntu 16.04 LTS, Mule ESB 3.8.1.
If this not work, it mean that you blocked that port (8081) on this machine (or firewall). Check iptables or another your 3th-party firewall.
Mule handle it easily by using the application properties. Create property files for each environment local|develop|prod.
local.properties
api.host=0.0.0.0
api.port=8080
prod.properties
api.host=127.0.0.1
api.port=9090
Read more about the mule service configuration management at https://docs.mulesoft.com/mule-runtime/3.9/configuring-properties.
I'm tearing my hair out over a JMeter config issue. I'm running JMeter on a dedicated injection server, using the gui on my local box to control the tests [EDIT: The connection is SSH. The client is Windows 7 and the server is Linux). I've run the tests from my local box and I confirmed that they're working correctly from there. I put the payload (text files containing one JSON object each) on to the injection server and changed the Publisher configuration in the message source section so the path pointed to the files on there and...nothing.
This is the only output I get:
2012/09/24 14:26:50 INFO - jmeter.engine.ClientJMeterEngine: running clientengine run method
2012/09/24 14:26:50 INFO - jmeter.samplers.StandardSampleSender: Using StandardSampleSender for this test run
2012/09/24 14:26:50 INFO - jmeter.samplers.StandardSampleSender: Using StandardSampleSender for this test run
2012/09/24 14:26:50 INFO - jmeter.engine.ClientJMeterEngine: sent test to <IP_ADDRESS_OBSCURED> basedir='.'
2012/09/24 14:26:50 INFO - jmeter.engine.ClientJMeterEngine: Sending properties {}
2012/09/24 14:26:50 INFO - jmeter.engine.ClientJMeterEngine: sent run command to <IP_ADDRESS_OBSCURED>
I don't know what I'm doing wrong. I tried Apache's highly comprehensive documentation, but surprisingly there's nothing at all about this. How should I be configuring the path to the payload on the server?
Coincidentally, I solved this one today and was on my way home to post the answer. The important thing to note is that the tests weren't running at all. The server reported stop-start but the tests weren't running. This is why:
I was using a JMS Producer sampler and connecting over SSH. This was part of the problem. In order to connect to a remote SSH server, it's necessary first to create an SSH tunnel, then start the JMeter server and client with special parameters. The process is described in this helpful and concise blog post:
http://blog.ionelmc.ro/2012/02/16/how-to-run-jmeter-over-ssh-tunnel/
The second mistake I was making was that I was running the server on a Linux box (CentOS) and the client on a Windows 7 desktop. It's not recommended to do this, but I didn't realise that it'd stop the test from running. I dropped a Linux VM on my windows box, ran the tests from there and everything worked perfectly.