I have an openldap server on RHEL 6.6 which is compiled to use moznss. I am running into problems with connecting, tls cannot start, I get errors like:
TLS: loaded CA certificate file /etc/pki/tls/certs/lcni_uoregon_edu_interm.cer.
TLS: error: tlsm_PR_Recv returned 0 - error 22:Invalid argument
TLS: error: connect - force handshake failure: errno 22 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
This is apparently a well-known issue, and as of a couple of years ago Howard Chu expressed doubts as to the readiness of moznss.
So, what is the current wisdom regarding which ssl/tls system to use? I've generally gone with openssl, though gnutls is newer, perhaps better?
Related
This is a very strange situation that's driving me nuts, and I would really appreciate some help here.
I am using CDK to define the DynamoDB table and associated indices. To test them locally, I installed cdklocal and DynamoDB local using localstack. When the computer (Mac running Ventura 13.1) is restarted, everything works as expected. Here is the script I use to bootstrap and start the stack (this is in a file called startStack.sh):
docker-compose up -d
echo "Waiting for 5 seconds"
sleep 5
cd test-app
cdklocal bootstrap
echo "Waiting for 5 seconds"
sleep 5
cdklocal deploy TestAppStack
#cdklocal deploy TestAppStack/ops-table
DYNAMO_ENDPOINT="http://localhost:4566/" dynamodb-admin &
open http://0.0.0.0:8001
cd ..
The test-app directory contains a local copy of the DynamoDB (and associated indices) definition. I do not encounter any errors running the cdklocal (or cdk) deploy commands so I am assuming that the CDK definition is not an issue.
The docker-compose looks like this:
version: "3.8"
services:
localstack:
container_name: AWS-DEVELOPMENT-WITH-LOCALSTACK
image: localstack/localstack:latest
network_mode: bridge
ports:
- "127.0.0.1:53:53"
- "127.0.0.1:53:53/udp"
- "127.0.0.1:443:443"
- "127.0.0.1:4566:4566"
- "127.0.0.1:4571:4571"
- "127.0.0.1:${PORT_WEB_UI-8080}:${PORT_WEB_UI-8080}"
environment:
- DYNAMODB_SHARE_DB=1
- DISABLE_CORS_CHECKS=1
- SERVICES=s3,dynamodb,sns,sqs,firehose,kinesis,ses,sts,cloudformation
- DEBUG=1
- DATA_DIR=/tmp/localstack/data
- PORT_WEB_UI=8080
- LAMBDA_EXECUTOR=local
- KINESIS_ERROR_PROBABILITY=1.0
- DOCKER_HOST=unix:///var/run/docker.sock
- HOST_TMP_FOLDER=./.localstack
volumes:
- './.localstack:/var/lib/localstack'
- '/var/run/docker.sock:/var/run/docker.sock'
Everything works as expected when I first run the startStack.sh file - the dynamodb-admin window opens up correctly and other interfaces can interact with the local DynamoDB table. But after some time (and I have not been able to pinpoint the cause), all interactions with local DynamoDB start failing with the following error(s):
Bootstrapping environment aws://000000000000/us-west-2...
❌ Environment aws://000000000000/us-west-2 failed bootstrapping: UnknownEndpoint: Inaccessible host: `localhost' at port `4566'. This service may not be available in the `us-west-2' region.
at Request.ENOTFOUND_ERROR (/usr/local/lib/node_modules/aws-sdk/lib/event_listeners.js:611:46)
at Request.callListeners (/usr/local/lib/node_modules/aws-sdk/lib/sequential_executor.js:106:20)
at Request.emit (/usr/local/lib/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
at Request.emit (/usr/local/lib/node_modules/aws-sdk/lib/request.js:686:14)
at error2 (/usr/local/lib/node_modules/aws-sdk/lib/event_listeners.js:443:22)
at ClientRequest.<anonymous> (/usr/local/lib/node_modules/aws-sdk/lib/http/node.js:99:9)
at ClientRequest.emit (node:events:513:28)
at ClientRequest.emit (node:domain:489:12)
at Socket.socketErrorListener (node:_http_client:494:9)
at Socket.emit (node:events:513:28) {
code: 'UnknownEndpoint',
region: 'us-west-2',
hostname: 'localhost',
retryable: true,
originalError: [Error],
time: 2023-01-15T06:46:40.614Z
}
Inaccessible host: `localhost' at port `4566'. This service may not be available in the `us-west-2' region.
The script hangs at the following message:
[16:52:01] Retrieved account ID 000000000000 from disk cache
[16:52:01] Assuming role 'arn:aws:iam::000000000000:role/cdk-hnb659fds-deploy-role-000000000000-us-west-2'.
[16:52:01] Assuming role failed: Inaccessible host: `localhost' at port `4566'. This service may not be available in the `us-west-2' region.
[16:52:01] Could not assume role in target account using current credentials Inaccessible host: `localhost' at port `4566'. This service may not be available in the `us-west-2' region. . Please make sure that this role exists in the account. If it doesn't exist, (re)-bootstrap the environment with the right '--trust', using the latest version of the CDK CLI.
current credentials could not be used to assume 'arn:aws:iam::000000000000:role/cdk-hnb659fds-deploy-role-000000000000-us-west-2', but are for the right account. Proceeding anyway.
[16:52:01] Waiting for stack CDKToolkit to finish creating or updating...
Restarting the computer fixes it, but it's not clear what causes the issue in the first place. Restarting Docker does not help either.
Any thoughts on what could be causing the problem and how I can avoid it?
I'm adding this as an answer, although I do not have an affirmative answer I thought I would try to help.
I believe your port is being occupied and thus the process you are running is unable to obtain it resulting in error. Before running the job, check if the port is occupied:
sudo lsof -i :4566
Sorry if this is a newbie question. I have been searching and can't seem to figure this out.
I am trying to move a PHP webapp from Plesk, to RunCloud. Both are hosted on a Digital Ocean server.
I exported the database from Plesk, and imported it into RunCloud. After updating the config, it only partially works. Some of the tasks read data, a few seem to write, but a majority just break it.
The strange thing is, if I point the config file to the Plesk server, the app works great using it as a remote database.
Here is from the PHPMyAdmin. The only thing that looks fishy is UNIX, vs TCP. But I cannot find a way to change RunCloud to UNIX.
I would copy the errors, but they are across the board. Any ideas? Thank you so much!
PHPMyAdmin Plesk Server:
Server: Localhost via UNIX socket
Server type: MariaDB
Server connection: SSL is not being used Documentation
Server version: 10.1.48-MariaDB-0ubuntu0.18.04.1 - Ubuntu 18.04
Protocol version: 10
User: prod#localhost
Server charset: UTF-8 Unicode (utf8mb4)
From RunCloud Server:
Server: 127.0.0.1 via TCP/IP
Server type: MariaDB
Server connection: SSL is not being used Documentation
Server version: 10.4.21-MariaDB-1:10.4.21+maria~focal-log - mariadb.org binary distribution
Protocol version: 10
User: prod#localhost
Server charset: UTF-8 Unicode (utf8)
As a newbie, I learned that 10.1 and 10.4 were rather different. I then went through each error to see if I could find the change on the MariaDB update guide (which is great). Somehow, I came across this post: error code 1292 incorrect date value mysql. It was the zero date. I just added the line in my.cnf that it suggested. Fixed!!!
I have two servers. One is using to build app service and the other is using to build hyperledger fabric network. When i request from app service to blockchain network then sometime i have some problem like below:
[client-utils.js]: sendPeersProposal - Promise is rejected: Error: 14 UNAVAILABLE: TCP Read failed
at new createStatusError (/home/user/server/node_modules/fabric-client/node_modules/grpc/src/client.js:64:15)
at /home/user/server/node_modules/fabric-client/node_modules/grpc/src/client.js:583:15
[Orderer.js]: sendBroadcast - on error: "Error: 14 UNAVAILABLE: TCP Read failed\n at createStatusError (/home/user/server/node_modules/fabric-client/node_modules/grpc/src/client.js:64:15)\n at ClientDuplexStream._emitStatusIfDone (/home/user/server/node_modules/fabric-client/node_modules/grpc/src/client.js:270:19)\n at ClientDuplexStream._receiveStatus (/home/user/server/node_modules/fabric-client/node_modules/grpc/src/client.js:248:8)\n at /home/user/server/node_modules/fabric-client/node_modules/grpc/src/client.js:804:12".
Is anyone know to solved this issue. Thanks so much. (sorry for my bad english)
I am having k8s cluster on centos7.2 with 1 master and 2 slaves. The cluster is working fine as far as it is serving on port 8080 but when I tries to secure Kube-API server by using certificates, I felt into the above error after restarting the kube-apiserver service and it is continuously writing this error in my log file at /var/log/messages.
kube-apiserver is started as-
KUBE_API_ADDRESS="--bind-address=0.0.0.0"
KUBE_API_PORT="--secure-port=6443"
KUBELET_PORT="--kubelet-port=10250"
KUBE_ETCD_SERVERS="--etcd-servers=http://kube-master:2379"
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"
KUBE_ALLOW_PRIV="--allow-privileged=true"
KUBE_API_TLS_CERT_FILE="--tls-cert-file=/home/abc/server.cert"
KUBE_API_TLS_PRIVATE_KEY_FILE="--tls-private-key- file=/home/abc/server.key"
KUBE_API_TOKEN_AUTH_FILE="--token-auth-file=/home/abc/token.csv" </br>
I am accessing API server using kubectl command as
kubectl --v=4 --server="https://$ip:6443" --certificate-authority="./ca.crt" --token="abcdTOKEN1234" get nodes
After that I am getting following error-
2930 helpers.go:153] Connection error: Get https://$ip:6443/api: x509: certificate signed by unknown authority
2930 helpers.go:96] Unable to connect to the server: x509: certificate signed by unknown authority
I performed same steps on ubuntu 14.04 and are working fine. I am not able to figure out where exactly I'm missing. Can anyone knows where I am wrong ? Thanks in advance.
I'm having trouble with setting up Sentry server in HTTPS mode. Every now and then, reasonably often while seemingly random, this error message gets written by Raven (Sentry client) into log files:
Unable to reach Sentry log server: <urlopen error [Errno 8] _ssl.c:504: EOF occurred in violation of protocol> (url: https://$(valid_server)/)
Web UI works fine. Vast majority of the messages from Raven are received fine and Sentry processes them into usable output. However, due to these errors, something gets lost from time to time.
I have tried to figure this one out, but dead ends seem to follow another. Basically it seems a lot like this:
Python Requests requests.exceptions.SSLError: [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
But when testing my Sentry server with similar s_client query using TLS 1.2, it leads to a valid session unlike with the example there.
It's also not about this, since SNI isn't used:
python-requests 2.0.0 - [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
I'm not able to reproduce the error coherently. Raven's tests are passed and nothing is acutely wrong, until an error pops up in the log.
My set up is: Raven 4.2.1 in Python 2.7.5, Nginx 1.6.0 as reverse proxy handling HTTPS, and finally Sentry 6.4.4 with default Gunicorn 0.17.4. Nginx configs are pretty much similar to official documentation (http://sentry.readthedocs.org/en/latest/quickstart/nginx.html) with a few alterations due to HTTPS.
I ran into the same issue and got it fixed by installing the following dependencies:
On Ubuntu:
sudo aptitude install libffi-dev
And then via pip:
pip install pyopenssl ndg-httpsclient pyasn1
The problem seems to be that Python 2.X doesn't support SNI (which is needed for TLS) out of the box as explained here.