I'm trying to deploy an instance to ec2 with the knife command line tool for chef. Running
knife --version
gives Chef: 11.14.0.alpha.1
I've configured my knife.rb file appropriately
knife[:aws_access_key_id] = 'ABSDGYRB7KXSFHGSF'
knife[:aws_secret_access_key] = 'SDHGsdbstsdsdgdfhdfAGSDGC5IOfqsdgdfhAS'
knife[:flavor] = 't1.micro'
knife[:aws_ssh_key_id] = 'myawskey'
knife[:identity_file] = "/Users/place/pem/myawskey.pem"
However when I run
knife ec2 server list
I get
FATAL: Cannot find sub command for: 'ec2 server list'
The ec2 commands were moved to plugins in Chef 0.10
You can install the plugin with `(sudo) gem install knife-ec2
But I've installed the package several times, each time with the same result.
Successfully installed knife-ec2-0.8.0
Parsing documentation for knife-ec2-0.8.0
Done installing documentation for knife-ec2 after 0 seconds
1 gem installed
What could be causing this, and what can I do to fix it?
I feel like it might have something to do with the alpha version of chef I'm running, but that's the version the chef developer kit installed so I'd like to imagine it would be stable. Any suggestions are appreciated. Thanks.
Following this turned out to fix the problem.
First step:
sudo xcode-select --switch /Library/Developer/CommandLineTools/
followed by:
sudo chef gem install knife-ec2
Related
I am trying to install SCVMM 2022 agent on AlmaLinux 9.
I discovered that the agent script is trying to use init.d while in AlmaLinux, there is no compatibility with init.d anymore but only systemd.
I updated the install script to copy the agent exec in /etc/systemd/system.
Now, I have a new error "Unable to find service control mechanism".
I understand that the script is unable to register the agent daemon in systemd.
How can I do to get the agent registered.
Have anyone ever have that issue with RedHat9 or any other forks in SCVMM 2022?
I'm just working on this (literally) right now, and while I can't get you a complete answer, I can tell you I've done the following and gotten it to at least install so I can create the template. Here's my notes up to this point, after creating the VM and copying the scvmm agent:
Install initscripts to create /etc/{init.d,rc.d,etc} folders
sudo yum install initscripts -y
https://centos.pkgs.org/9-stream/centos-baseos-x86_64/initscripts-10.11.1-1.el9.x86_64.rpm.html
Run install script for scvmm
sudo ./install scvmmguestagent.1.0.0.544.x64.tar
https://learn.microsoft.com/en-us/system-center/vmm/vm-linux?view=sc-vmm-2022
Shut down VM in VMware
Clone to template
I noticed that they don't offer RHEL 9 in their Guest OS Profile, so it may only be half supported. I'm also using VMware, you may have better luck if you're using Hyper-V
I have been deploying my service on App Engine for a long time now and never had an issue until today.
Command to Deploy
gcloud app deploy app.yaml
Output
Beginning deployment of service [default]...
Building and pushing image for service [default]
ERROR: gcloud crashed (ModuleNotFoundError): No module named 'distutils.spawn'
I just deployed this morning with no issues and randomly when I tried to redeploy now I get the above error. Hopefully someone can help figure out what caused this issue.
For info:
app.yaml
runtime: custom
env: flex
manual_scaling:
instances: 1
resources:
cpu: 1
memory_gb: 4
disk_size_gb: 10
Gcloud version
$ gcloud --version
Google Cloud SDK 341.0.0
alpha 2021.05.14
beta 2021.05.14
bq 2.0.68
core 2021.05.14
gsutil 4.62
minikube 1.20.0
skaffold 1.23.0
I had a similar issue, on my case this was the solution:
sudo apt-get install python3-distutils
Same exact problem.
Building and pushing image for service [default]
ERROR: gcloud crashed (ModuleNotFoundError): No module named 'distutils.spawn'
This issue seemed to be in the snap install of google-cloud-sdk in Ubuntu 20.04.2 LTS (You can select it pre-installed during the ISO setup.. DONT)
I was getting this in 18.04 as well
FINALLY solved it..
But.. I had to make sure I did not snap install google-cloud-sdk
I also..
sudo apt update
sudo apt upgrade
Then I made sure the snap install was not installed. (After a fresh install of Ubuntu). Sense I use dockerfiles it's easy for me to zap a dev environment and get it back.
But Id imagine if you can't zap your os and make sure not to let the OS put it's snap install of google-cloud-sdk.. You could snap remove google-cloud-sdk and then hunt for all it's configuration files.. And remove them.
At that point
https://cloud.google.com/sdk/docs/install#deb
Follow that... I did so exactly... FINALLY seemed to work. I used the apt install route they explain.. NOT the snap.
I tried all the pip install sudo apt-get install python3-distutils Till I was blue in the face... NADA.
somehow.. The Snap being present puts PATH settings that use the wrong distutils.
On my box now that I search for it.. In Totally fresh OS state... No Snap install and going through exactly the cloud.google.com/sdk/docs/install#deb work..
Here is distutils everywhere on my box in Ubuntu 20.03.2 LTS
$ sudo find / -name distutils
/snap/lxd/19188/lib/python2.7/distutils
/snap/core18/1944/usr/lib/python3.6/distutils
/snap/core18/1944/usr/lib/python3.7/distutils
/snap/core18/1944/usr/lib/python3.8/distutils
/usr/lib/python3.8/distutils
/usr/lib/python3.9/distutils
/usr/lib/python2.7/distutils
Note.. There's no google-cloud-sdk in the snap!!
The gcloud app deploy FINALLY works!! Passes the part where it starts to deploy.
But as the others in this.. It happened completly random.
All I can guess is...... Something clobered distutils as an update somewhere and started pointing to a garbage path.
Make sure you search for distutils find out where it is.. what's referencing it.. Somewhere in that mess you can fix it.
One thing I was able to discover is this problem will come default from 20.04.2.
I downloaded the most recent iso.. thinking it was an 18.04 issue.
Installed it fresh into Virtual Box.. And got exactly this same issue. So my solution fix (no SNAP).. Is against a totally clean 20.04.2 brand spanking new Ubuntu LTS VM. Default everything.
===============
Regarding the random one day it worked.. the next it didn't...
Here's the thing about snaps in Ubuntu:
https://www.google.com/search?q=Do+snap+packages+update+automatically%3F&rlz=1C1CHBF_enUS834US834&ei=ygynYJGRIo3f-gSLzb3YDg&oq=Do+snap+packages+update+automatically%3F&gs_lcp=Cgdnd3Mtd2l6EAMyCAghEBYQHRAeUJ-TCVifkwlgj5kJaABwAXgAgAFziAHVAZIBAzEuMZgBAKABAqABAaoBB2d3cy13aXrAAQE&sclient=gws-wiz&ved=0ahUKEwiRnrfXz9nwAhWNr54KHYtmD-sQ4dUDCA4&uact=5
"Do snap packages update automatically?
Snaps update automatically, and by default, the snapd daemon checks for updates 4 times a day. Each update check is called a refresh."
so that's how it randomly broke if you used a snap
I am installing Postgres on CentOS 7 boxes, and that part itself is fine. The issue that someone brought up is that they would like for my install script to try and not depend on the service name being postgresql-10, and instead just use postgres or postgresql. Either one would be fine. Well I noticed that there is a flag --servicename that can be used, but I am unsure where to use it in the process. I have tried a few times but it doesn't seem to work.
Note that this is how I am installing postgres
yum -y install $LINK
yum -y install postgresql10
yum -y install postgresql10-server
/usr/pgsql-10/bin/postgresql-10-setup initdb
systemctl enable postgresql-10
systemctl start postgresql-10
the $LINK up there is just the path to pull from the Postgres website. Again, the ideal situation would be for me to specify the service name such that I can standardize that and limit script changes when Postgres versions change.
Note that I found out about the --servicename flag in this, link but I am not completely sure how to apply that to the installation above. It does appear that the link is more for installing on windows, but I would assume we could do the same thing in a Linux installation. Any suggestions here would be welcome.
The link that you found is about EnterpriseDB's installer for Windows, and the service mentioned is a Windows service. That won't help you on CentOS.
The name of the systemd service file is hard-wired into the RPM, but there is nothing that prevents you from creating your own service file in /etc/systemd/system and using that one instead. Then you can choose whatever name you prefer. You can just copy the service file from the RPM as a starting point.
Renaming the file or creating one in /usr/systemd/system is not a good idea, because that will mess with RPMs.
postgresql-10 is a good name for the service, however. If you choose postgres or something else that doesn't contain the version, what will you do once you want to install v11?
To answer your question: There is no way to configure the name of the service when installing it via RPM.
I created a machine in AWS Cloud9 and I want to install timescale on that instance. I have previously installed and setup postgres 9.6 using yum.
OS version is:
Amazon Linux AMI release 2018.03
.
When I run 'which pg_config', it is found here:
/usr/bin/pg_config
Looking at the install instructions on the timescale website, I came up with this:
sudo yum install -y
https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-6-x86_64/pgdg-ami201503-96-9.6-2.noarch.rpm
wget
https://timescalereleases.blob.core.windows.net/rpm/timescaledb-0.9.2-postgresql-9.6-0.x86_64.rpm
sudo yum install timescaledb-0.9.2-postgresql-9.6-0.x86_64.rpm
after the last command I get the following error:
Running transaction Installing :
timescaledb-0.9.2-0.el7.centos.x86_64
1/1 ERROR: Could not find pg_config, expected it at
/usr/pgsql-9.6/bin/pg_config. Please fix and try again.
warning: %post(timescaledb-0.9.2-0.el7.centos.x86_64) scriptlet
failed, exit status 1 Non-fatal POSTIN scriptlet failure in rpm
package timescaledb-0.9.2-0.el7.centos.x86_64
Do you have any more details on how you installed PostgreSQL on CentOS? I suspect this may have something to do with a mismatch between your pg_config installation and your PostgreSQL 9.6 installation, similar to the user in this issue.
I'd recommend uninstalling your current postgresql-devel and explicitly installing it for 9.6:
yum install postgresql96-devel
It seems the AMI is setup a bit differently than a normal CentOS install so PostgreSQL is installed in a different place than our installer expected. I've gone ahead and updated the RPMs to use a more robust method of finding the correct place to put the files. If you could re-download the latest RPM and confirm that it works that'd be great.
I've met exactly the same problem.
I solve this by manually linking them together.
sudo ln -s /usr/lib64/pgsql96/bin/pg_config /usr/pgsql-9.6/bin/pg_config
I'm trying to install rocketchat-server, but it seems I can't make it work on my VPS.
I've installed snap just fine. Now that I try to hint the command line :
sudo snap install rocketchat-server
I get the following error message :
error: snap "rocketchat-server" not found
Going through the web, nobody seems to get that error, so I'm a little confused as to what to do next. I was supposed to get a functionnal RocketChat Server within 30 seconds, but it's been hours and I can't seem to understand what is wrong.
What I'm trygin to accomplish :
install RocketChat on my VPS
my VPS is on Ubuntu 16.04.3 LTS
if I run uname -i I get aarch64, sooo I'm guessing I have a 64 bits OS ? (the
docs say 32 bit is not supported)
by the way I'm testing rocketchat on a Scaleway server (a friend told me that it could be the problem, but well, i'm not knowledgeable enough)
Thank you for your answers (and sorry for my non native english)
I think I found the solution to your problem.
(https://websetnet.net/de/why-do-you-see-error-snap-xyz-not-found/)
Try to install snapd
sudo apt install snapd
Then install with snap rocket.chat
sudo snap install rocketchat server
The problem is that the snap package on Ubuntu doesn't have anything to do with snapd.
(https://github.com/anbox/anbox/issues/146#issuecomment-298157614)