I am trying to renew GitLab letsencrypt certificate for my standalone Gitlab-ce installation.
But it failed for some reason.
the result is as follow,
Acme::Client::Error::Timeout
----------------------------
Acme::Client::Error::Timeout
chef_version=15.17.4
platform=ubuntu
platform_version=20.04
ruby=ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-linux]
program_name=/opt/gitlab/embedded/bin/chef-client
executable=/opt/gitlab/embedded/bin/chef-client
Running handlers:
Running handlers complete
Chef Infra Client failed. 0 resources updated in 01 minutes 05 seconds
There was an error renewing Let's Encrypt certificates, please checkout the output
Any help is appreciated.
Thank you
I solved the same problem by clearing all the certificates (.crt and .key files) in /etc/gitlab/ssl and then running gitlab-ctl reconfigure. it made new ones.
This might not be a good solution for everyone but in my case, it worked. Also, I found that the /etc/gitlab/gitlab.rb had several 'nil' values in the letsencrypt area including whether it was enabled and the minute value that the generator is supposed to run at. I set the minute value to 0, as well as letsencrypt['enable'] = true
Related
Hope everyone is keeping safe!
I have a Ruby on Rails application hosted on AWS Beanstalk. I am using CloudFormation template, to update any stack for e.g., Ruby version, Linux Platform upgrade etc.
I was trying to upgrade, Linux box to 2.11.7 and Ruby to 2.6.6 and then ElasticSearch to 7.4
I was doing these changes in CloudFormation YML template and then I ran aws cloudformation update-stack command to apply these changes.
While the changes took time, I accidentally clicked on Rebuild Environment from Web AWS Console as a result, all the previously configured settings like SQS, Load balancer etc., were replaced by new settings.
Now, whenever I am trying to execute the update-stack command, it fails with below errors:
2020-06-09 15:25:44 UTC+0530
WARN
Environment health has transitioned from Info to Degraded. Command failed on all instances.
Incorrect application version found on all instances. Expected version "code-pipeline-xxxxxxxxxx" (deployment 2377). Application update failed 40 seconds ago and took 79 seconds.
2020-06-09 15:25:03 UTC+0530
INFO
The environment was reverted to the previous configuration setting.
2020-06-09 15:24:44 UTC+0530
INFO
Environment health has transitioned from Ok to Info. Application update in progress on 1 instance. 0 out of 1 instance completed (running for 39 seconds).
2020-06-09 15:24:30 UTC+0530
ERROR
During an aborted deployment, some instances may have deployed the new application version.
To ensure all instances are running the same version, re-deploy the appropriate application version.
2020-06-09 15:24:30 UTC+0530
ERROR
Failed to deploy application.
2020-06-09 15:24:30 UTC+0530
ERROR
Unsuccessful command execution on instance id(s) 'i-xxxxxxxxxx'. Aborting the operation.
2020-06-09 15:24:30 UTC+0530
INFO
Command execution completed on all instances. Summary: [Successful: 0, Failed: 1].
2020-06-09 15:24:30 UTC+0530
ERROR
[Instance: i-xxxxxxxxxx] Command failed on instance. Return code: 18 Output: (TRUNCATED)...g: the running version of Bundler (1.16.0) is older than the version that created the lockfile (1.17.3). We suggest you upgrade to the latest version of Bundler by running `gem install bundler`. Your Ruby version is 2.6.6, but your Gemfile specified 2.6.5. Hook /opt/elasticbeanstalk/hooks/appdeploy/pre/10_bundle_install.sh failed. For more detail, check /var/log/eb-activity.log using console or EB CLI.
2020-06-09 15:24:19 UTC+0530
INFO
Deploying new version to instance(s).
2020-06-09 15:23:45 UTC+0530
INFO
Updating environment developWeb's configuration settings.
2020-06-09 15:23:36 UTC+0530
INFO
Environment update is starting.
I can confirm that I have Ruby-2.6.6 set. I am not sure from where it is picking up the old version of Ruby?
Is there any way I can fix this? OR forcefully apply template changes?
Any help on this would be highly appreciated.
[UPDATE]: When I try to connect to ElasticSearch from Rails console, I get:
Faraday::ConnectionFailed: Failed to open TCP connection to old-elasticsearch-host-name.es.amazonaws.com:80 (Hostname not known: old-elasticsearch-host-name.es.amazonaws.com)
from /opt/rubies/ruby-2.6.6/lib/ruby/2.6.0/net/http.rb:949:in `rescue in block in connect'
Caused by SocketError: Failed to open TCP connection to old-elasticsearch-host-name.es.amazonaws.com:80 (Hostname not known: old-elasticsearch-host-name.es.amazonaws.com)
from /opt/rubies/ruby-2.6.6/lib/ruby/2.6.0/net/http.rb:949:in `rescue in block in connect'
Caused by Resolv::ResolvError: no address for old-elasticsearch-host-name.es.amazonaws.com
from /opt/rubies/ruby-2.6.6/lib/ruby/2.6.0/resolv.rb:94:in `getaddress'
The new URL of elasticsearch instance is different but it is still picking up the old URL from ELASTICSEARCH_HOST ENV variable.
Information from my CF template:
I can now provide info as per request. please tag me to see what I have in CF template
This was a config issue.
Whenever I was running aws update-stack command, it was going to s3 and pulling the zip (of the source code) code and in Gemfile of that zip code ruby version was set to 2.6.5.
So, I'd uploaded the fresh copy of the source code and then executed the update-stack command and it worked
It's really frustrating, wasted 3 days to get rid of but still on stuck problem showing on macos catalina version 10.15.1 and windows 7 also. My two PC's showing same error. First when i tried to 'get packages'
it's showing this '/Users/mamun/Developer/flutter/bin/flutter --no-color packages get
Waiting for another flutter command to release the startup lock...'
after few moments it's showing..
'/Users/mamun/Developer/flutter/bin/flutter --no-color packages get
Running "flutter pub get" in flutterx...
Connection terminated during handshake
pub get failed (server unavailable) -- attempting retry 1 in 1 second...
Connection terminated during handshake
pub get failed (server unavailable) -- attempting retry 2 in 2 seconds...,
tried this Waiting for another flutter command to release the startup lock
& https://github.com/dart-lang/pub/issues/1729 also.
This is a country-specific problem. In some countries, you got this error like Bangladesh and some African countries. I got a solution to this problem, that is use VPN software when you want to get Packages. VPN software uses other country's IP addresses where this google service works perfectly, So you can easily download packages.
Fixed the issue, my Local Isp blocked pub.dartlang.org that's why it happens.
Use vpn.
If you are not using not prepackaged packages:
stop the process with "ctrl + c"
and try it on project location:
flutter pub get --offline
Use VPN. Or download package from github.
dependencies:
flutter:
sdk: flutter
carousel_pro:
git:
url: https://github.com/jlouage/flutter-carousel-pro.git
ref: master
detailed answer is here:
I was using Hotspot VPN when I faced this issue. Disabling the hotspot worked for me. You can check by disabling any HotSpot or VPN.
Download the stable version instead of the clone via git:
C:\src>git clone https://github.com/flutter/flutter.git -b stable)
I'm setting up a honeypot for my boss, and I'm coming across an issue with actually getting the time to synchronize with my workstations time (the reason I want to achieve this is because before looking at the steps on the link below, I had NOOBS rasbian OS installed which had the same issue with not being able to clone, but after doing the following command sudo apt-get install ntp, I was able to clone the files into the system with no issues, but because the link below calls for the "Rasbian Stretch Lite OS", I had to re-do the process, and because of this I can't seem to get the time to sync anymore.
https://github.com/DShield-ISC/dshield
So when I attempt to do the following command in the steps:
git clone https://github.com/DShield-ISC/dshield.git
fatal: unable to access 'https://github.com/DShield-ISC/dshield.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
I've Tried the following methods with no luck:
sudo /etc/init.d/ntp stop
sudo raspi-config (setting timezone)
sudo /etc/init.d/ntp start
the timedatectl settings are as follows:
Local time: Mon 2016-02-04 12:04:52 PST
Universal time: Mon 2016-02-04 20:04:52 UTC
RTC time: n/a
Time zone: America/Los_Angeles (PST, -0800)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
Also i've tried..
sudo ntpd -q -g
I've noticed with this command I get a ton of results, and the process never finishes, if this is vital I can re-run the command and tell you what kind of information is coming back to me.
Yes I've set the time to be as close as possible to the actual clock before attempting any of these, I've noticed that regardless it's always either a minute or some seconds off, whenever rebooting. I'm assuming that's because it isn't synchronized even though it states that it is.
The Cert error was due to me being HARDWIRED into my RBI verses using wifi, after going into sudo raspi-config, and setting up a wifi connection I was able to successfully clone the github repo.
I'm developing a program to automatically renew my SSL certificates for my server.
Currently, the command to renew SSL certificates is /opt/certbot-auto certonly --keep --no-bootstrap --no-self-upgrade --non-interactive --webroot -w /usr/share/nginx/html -d myDomain.
I'm wandering if I should remove --no-self-upgrade options in the command. Because if I don't upgrade certobot-auto, I'll get a warning saying Attempting to parse the version <new_version> renewal configuration file found at XXX with version <old_version> of Certbot. This might not work.. I'm afraid some day in the future, the program will not be able to renew the SSL certificates on my machine if I don't upgrade certbot-auto.
If I remove --no-self-upgrade, should I also remove --no-bootstrap? Because new versions of certbot-auto might have different OS dependencies.
Yes, I would recommend removing those flags.
Also, since you're using Nginx, you probably want to use Certbot's built in Nginx support. To do this, run once with just /opt/certbot-auto --nginx, and follow the prompts, including saying yes to renewing a certificate even though you already have one. That will save the renewal settings using the Nginx support.
You can then change your cron job to simply /opt/certbot-auto -q renew, which will automatically renew all previously issued certificates, and reload Nginx.
Using chef solo, calling it directly - with logging set as high as possible, this is what I see in a tail:
[2015-03-24T12:21:48+11:00] INFO: Forking chef instance to converge...
[2015-03-24T12:21:48+11:00] DEBUG: Fork successful. Waiting for new chef pid: 5571
[2015-03-24T12:21:48+11:00] DEBUG: Forked instance now converging
[2015-03-24T12:21:49+11:00] INFO: *** Chef 11.8.2 ***
[2015-03-24T12:21:49+11:00] INFO: Chef-client pid: 5571
[2015-03-24T12:25:41+11:00] DEBUG: Building node object for localhost.localdomain
...
and then it continues and goes on to work perfectly. Notice in between the last two lines, there is a delay which varies between 3 and 5 minutes! With no explanation of what it's doing, nothing obvious on netstat or top - I'm at a loss for how to troubleshoot this.
I thought it might be a proxy thing, but setting the correct proxies in /etc/chef/client.rb changed nothing. Any ideas how I get rid of this delay?
The first thing that Chef does when it starts - whether it's chef-solo or chef-client, is profile the system with ohai.
A main difference between chef-solo and chef-client is that debug log level will show the ohai output with chef-client, but it does not with chef-solo.
Depending on your system's configuration, this can take a long time to do, as it runs through a plethora of plugins. In particular, if you have a Linux system that is connected to Active Directory, it can take awhile to retrieve the user/group records via AD, which is why Ohai supports disabling plugins. Also, if you're running Chef and Ohai on a Windows system, it can take a long time.
To disable plugins, you need to edit the appropriate application's configuration file.
chef-solo uses /etc/chef/solo.rb by default
chef-client uses /etc/chef/client.rb by default
Add the following line to the appropriate config:
Ohai::Config[:disabled_plugins] = [:Passwd]
to disable the user/group lookup that might use Active Directory.
Also, I see from the output that you're using Chef 11.8.2 which came out December 3, 2013 (over a year ago as of this answer). It's possible that a performance improvement was introduced since then.
However, if you're not specifically beholden to chef-solo, you might try using chef-client with local mode. There is more information about how to switch in a blog post by Julian Dunn on Chef's site. If you need further assistance I strongly suggest the Chef irc channel on irc.freenode.net, or the chef mailing list.