I was running the code build when it threw this error
[Container] 2018/10/18 00:43:55 Running command $(aws ecs stop-task --task arn:aws:ecs:ap-southeast-1:502776083946:task/207cfc8b-914d-4c4b-9c8a-0ffbfcef6924 --cluster arn:aws:ecs:ap-southeast-1:502776083946:cluster/timesheet-staging-cluster)
/usr/local/lib/python2.7/dist-packages/urllib3/util/ssl_.py:369: SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
SNIMissingWarning
/codebuild/output/tmp/script.sh: 4: /codebuild/output/tmp/script.sh: {: not found
How do I resolve this? I need the ECS tasks to be stopped in order for a new task to be deployed
Related
For several months now I've had issues with gitlab-runner which is randomly failing with the following log:
Running with gitlab-runner 13.7.0 (943fc252)
on <gitlab-runner-name> <gitlab-runner-id>
Preparing the "shell" executor
00:00
Using Shell executor...
Preparing environment
00:00
Running on <hostname>...
Getting source from Git repository
00:00
Fetching changes...
Reinitialized existing Git repository in /var/gitlab-runner/builds/<gitlab-runner-id>/0/<gtlab-group>/<gitlab-project>/.git/
fatal: unable to access 'https://gitlab-ci-token:[MASKED]#<hostname>/<gtlab-group>/<gitlab-project>.git/': Problem with the SSL CA cert (path? access rights?)
ERROR: Job failed: exit status 1
This line is the crucial one:
fatal: unable to access 'https://gitlab-ci-token:[MASKED]#<hostname>/<gtlab-group>/<gitlab-project>.git/': Problem with the SSL CA cert (path? access rights?)
I tried unregistering the runner and registering a new one. It also failed with the same error after a while (the first run usually worked well).
Furthermore, runners on other machines are working correctly and never fail with the error message above.
I believe the issue is caused by the missing CI_SERVER_TLS_CA_FILE file in:
/var/gitlab-runner/builds/<gitlab-runner-id>/0/<gtlab-group>/<gitlab-project>.tmp/CI_SERVER_TLS_CA_FILE
I tried doing a git pull in the faulty directory and I got the same message. After I copied this missing file from another directory which had it, I got the following:
remote: HTTP Basic: Access denied
fatal: Authentication failed for 'https://gitlab-ci-token:<gitlab-runner-token>#gitlab.lab.sk.alcatel-lucent.com/<gtlab-group>/<gitlab-project>.git/'
As far as I know, these tokens are generated for a one-time use and are discarded after the job finishes. This leads me to believe the missing file is the issue.
Where is this file copied from? Why is it missing? What can I do to fix this issue?
I've been looking through the GitLab issues without luck.
It sounds like one or more of your runners doesn't trust the certificate on your gitlab host. You'll have to track down the root and intermediate certs used to sign your TLS cert, and add it to your runners' hosts.
For my runners on CentOS, I follow this guide (for CentOS, the commands are the same for higher versions): https://manuals.gfi.com/en/kerio/connect/content/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html.
I am using kafka version 2.12-2.2.1 in windows operating system. I have implemented tls on my local windows systems using the process of signed certificates.
The kafka is running fine and there is one command to check if certificates are installed on kafka.
openssl s_client -debug -connect localhost:9093 -tls1
But when I try to connect to localhost:9093 and using producer or consumer it is throwing me an error saying :
connection to node -1 failed due to authentication
I have tried everything, I am stuck even the documentation provided is not giving any hints to solve this error.
Note: One more addition how can I see the list of topics and describe the topic if exits using ssl in kafka because that command is also not working.
Along with that I have tried every answer on SO but still no success.
The documentation I have followed Installing ssl on kafka
I'm using kafka version kafka_2.12-2.0.0 and received the below error after enabling SSL authentication. It seems to be working fine with previous versions: kafka_2.12-1.1.0, 2.11-0.10.2.2 etc.
I don't understand why it is not working with latest version 2.11-0.2.0.0? Has anyone observed the same issue that I'm facing right now with 2.0.0 version.
Below is my test environment docker config file.
listeners=PLAINTEXT://:9092,SSl://:9093
ssl.client.auth=required
ssl.keystore.location=/path/to/server.keystore
ssl.keystore.password=<Key store password>
ssl.key.password = <private key password>
ssl.truststore.location=/path/to/truststore.keystore
ssl.truststore.password=<trust store password>
security.inter.broker.protocol=SSL
And here's the error:
[2018-10-01 09:33:38,984] ERROR [Controller id=1, targetBrokerId=1] Connection to node 1 failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
Can someone help me ?
Without more details it's hard to tell for sure, but 2.0.0 introduced a change of behaviour related to the handling of SSL connections.
As mentioned in the 2.0.0 upgrade notes, the broker setting ssl.endpoint.identification.algorithm is now set to https. This enforces hostname verification to prevent "man-in-the-middle" attacks.
To restore previous behaviour, you need to explicitely set this to an empty string.
ssl.endpoint.identification.algorithm=
Was also facing a similar issue. My issue, I was having Kafka server 1.1.1 running and was using Kafka client 2.1.0 to push records. Changing Kafka client to 1.1.1 solved my issue.
Hope this helps.
I have been trying to configure a simple pass through proxy using wso2 esb, which points to a REST service in https port.
I had tried doing the same using my development machine (Windows 7) and it is successful.
But when I try repeating the same in production server, in RHEL, I get The system cannot infer the transport information error in system log.
Things Tried
Created passthrough proxy service pointing to https://some.domain.in/something/something.
Tried CURL to https://some.domain.in/something/something and its shows the response properly
Imported certificate from the site to client-truststore.jks. Same was done locally and it worked.
in axis2.xml, edited <parameter name="HostnameVerifier">AllowAll</parameter>under https transporter
Error Message
When clicked in test in configuration console, I got the following message, Invalid address
CURL the proxy service URL, and got Empty response
Checked system logs and saw below logs
Am I missing out something?
I could see in the wso2-error-logs following messages
ERROR {org.apache.synapse.transport.passthru.TargetHandler} - I/O
error: handshake alert: unrecognized_name
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
Then I realised that I was using java 1.6 locally but 1.7 in production.
And in Java 1.7 there are some changes in SSL handling
The JDK 7 release supports
the Server Name Indication (SNI) extension in the JSSE client. SNI,
described in RFC 4366 enables TLS clients to connect to virtual
servers.
In order to bypass this, I added JAVA_OPTS="-Djsse.enableSNIExtension=false" in wso2server.sh and restarted.
This solved my problem.
Not sure if this is the correct way though
This url helped me finally
I'm trying to diagnose this error:
Getting distribution for 'zc.buildout<2dev'.
Got zc.buildout 1.7.1.
Generated script '/opt/mytardis/releases/a549cd05272afe8f16c2fe5efe8158490acbde82/bin/buildout'.
Download error on http://pypi.python.org/simple/buildout-versions/: [Errno 104] Connection reset by peer -- Some packages may not be found!
Couldn't find index page for 'buildout-versions' (maybe misspelled?)
Download error on http://pypi.python.org/simple/: [Errno 104] Connection reset by peer -- Some packages may not be found!
Getting distribution for 'buildout-versions'.
STDERR: /usr/lib64/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: 'src_root'
warnings.warn(msg)
While:
Installing.
Loading extensions.
Getting distribution for 'buildout-versions'.
Error: Couldn't find a distribution for 'buildout-versions'.
It happens deep inside a Chef + buildout installation stack. One thing I have discovered is that if I attempt to access the buildout-versions package directly:
$ wget https://pypi.python.org/packages/source/b/buildout-versions/buildout-versions-1.7.tar.gz#md5=731ecc0c9029f45826fa9f31d44e311d
--2013-07-09 12:50:18-- https://pypi.python.org/packages/source/b/buildout-versions/buildout-versions-1.7.tar.gz
Resolving proxy.redacted.com... 123.45.67.8
Connecting to proxy.redacted.com|123.45.67.8|:8080... connected.
ERROR: certificate common name “*.a.ssl.fastly.net” doesn’t match requested host name “pypi.python.org”.
To connect to pypi.python.org insecurely, use ‘--no-check-certificate’.
I can access the file fine from my desktop. So I suspect the proxy (provided by a university, and this server has to use it to reach the web). It's set with https_proxy=....
Is this the likely cause of buildout failing? Any way around it?
Your version of wget is too old.
wget started to support SNI (Server Name Indication) only since version 1.14 and that TLS extension is needed to be presented the correct certificate on pypi.python.org.
Yes, zc.buildout and easy_install both use urllib2 to retrieve HTTPS resources, which does not verify SSL certificates:
Warning: HTTPS requests do not do any verification of the server’s certificate.
Your wget tool does verify certificates, but your local certificate authorities certificates are incomplete, it seems; see SSL certificate rejected trying to access GitHub over HTTPS behind firewall for instructions on how to update those.
As for your original error, it appears your firewall proxy is doing the peer resets.
As per PEP 476, Python 2.7.9 remedies this situation. From that version onwards, urllib2 will verify SSL certificates by default.
Since Python 2.7.9 (released) / 3.4.3 (released soon), certificates are validated by default:
HTTPS certificate validation using the system's certificate store is
now enabled by default. See PEP 476 for details.
https://www.python.org/downloads/release/python-279/
you can try it:
wget http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c11-py2.7.egg#md5=fe1f997bc722265116870bc7919059ea --no-check-certificate