We are used to use this repository to download kubelet and kubeadm packages - https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64/Packages
but it's unavailable now, I mean it's empty from RPMs since yesterday.
Can't find those rpms anywhere online and also there is not a status page or update from google that they are taking it down.
The kubernetes documentation still points to this entry and it's empty.
ideas ?
The Kubernetes documentation still points to this entry and it's empty.
Actually this page (The Official Kubernetes Installation Guide) explains that.
ideas ?
The guide suggests adding the repo under the the list of YUM repos. I have been installing k8s components from the following source with no issues.
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl
EOF
They seem to be there just fine for me, https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64/Packages/29e7806d1d54cc0eea2963f4ab276778526538816c88c963ece7d1a05fd80792-cri-tools-1.0.0_beta.1-0.x86_64.rpm for example. If you just mean the web server doesn't show the file list for those folders, yes because it's huge.
Related
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
Mine is a Windows 10 computer.
I ran the following command to install official kubernetes helm charts repository.
helm repo add stable https://charts.helm.sh/stable
The installation was successful as it says.
I wanted to understand where they are installed.
Searched on my home folder, and also ProgramData but could not find.
Any help would be appreciated.
Watching some videos, just found the answer.
Run the following command.
helm env
And you should see all the relevant locations.
And note, this works on ubuntu as well!
These docs describe the helm default file location per operating system.
According to them, your repository files should be under %TEMP%\helm.
I'm currently running helm 3.0.0 in ubuntu and want to upgrade to helm > 3.0.2 for gitlab. The install instructions suggest it's as simple as deleting the helm binary and downloading the new one and the release notes all suggest there are no breaking changes. Could it possibly be that simple?
It should be that simple, provided you put the binary in the right place in your path (i.e. replace the one that you already get from which helm, assuming you're on unix).
You could test it by running some of the following helm commands:
helm version will tell you what you're running.
helm list will
tell you what you have installed in your cluster (add -n
<namespace> for a different namespace)
If you're ok to temporarily install something into the cluster, follow a helm example to install something and then delete it again with a helm delete
We use custom yum repos at our company. Something is causing them to fail the yum makecache command.
I'm on CentOS Linux release 7.7.1908 (Core).
Here's the error that we get when we run yum makecache:
One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this
The repos look like this and I need to use both of them.
Epel repo:
[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel-debuginfo]
name=Extra Packages for Enterprise Linux 7 - $basearch - Debug
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
Our company repo:
[mmp]
name=MMP
baseurl=http://10.245.19.168/mmp_repo/
gpgcheck=0
enabled=1
I'm not sure what the problem is. How can I make this error go away?
This question is solved here. So, first, some background: When yum installs a package, it unpacks and moves all of the files to the proper directory (i.e. opt, bin, etc etcetera). When a network connection is interrupted, a drive-write is stopped, what have you, during the install process, some files might not be written, while the program still returns that it was installed successfully.
To fix this:
On the host where the installation is failing, check if the repos are correct.
Especially the baseurl
# grep 'baseurl' /etc/yum.repos.d/* | grep HDP
Just append "/repodata/repomd.xml" in the URL and then test if it is accessible.
Example: if baseurl is http://public-repo-1.hortonworks.com/HDP/centos7/2.x/updates/2.6.3.0 then try accessing it as following to verify the access. Please check all the URLs
# curl -v http://public-repo-1.hortonworks.com/HDP/centos7/2.x/updates/2.6.3.0/repodata/repomd.xml
If the URLs are accessible then in that case try cleaning the yum cache by running the command.
# yum clean all
After yum clean try running the following command again to verify if the issue persist.
# yum -y install ranger_2_6_3_0_235-admin
This seems to be a problem with the EPEL repository. Try yum with
--disablerepo=epel\*
until they get this fixed.
if you don't have an immediate need to get packages from EPEL, use yum with
--disablerepo=epel
until your local mirror syncs. yum clean all may or may not help, depending on which mirror you hit.
My general suggestion is still valid, though -- unless you have an immediate need to get EPEL packages, I would suggest using
--disablerepo=epel
until your local mirror gets the fixed repodata. If you do have an immediate need for EPEL packages and
yum clean all
does not help, you will need to adjust your config to point to some specific mirror that has the fixed content, like by adding baseurl=http://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/epel/7/
$basearch to epel.repo. Most mirrors should be updated by now, though.
Alternatives >>>
I happened to be on Freenode channel #epel when someone complained about this issue, but if this had happened to me, I could have enabled one repository at a time (with --disablerepo=* and --enablerepo=somerepo) to find which repo caused the trouble.
skip_if_unavailable=1 for non-critical repos sounds like a good idea.
Many people need only a few packages from EPEL. One option would be to import the EPEL packages you need to some locally controlled repository and use that instead. createrepo is related to this.
Top
Check your network connectivity. If you can't see your system ip address, then you should check & make network connectivity properly.
I faced this issue. I used CentOS 7 in VM ware. If I execute "ifconfig" command, it will show one IP address only. But generally in VM ware it should show two ip addresses. So if you can see only one IP address, then shutdown your linux system. Then change your Network Settings (Network Adapter) in VM ware.
Try this, it will work...!
We have a Spacewalk server we use to distribute updates to our CentOS 6 and 7 client systems. None of the client systems have internet access. Only the spacewalk server has restricted access to complete repo sync updates.
We have an issue when it comes time to push out the centos-release rpms. this rpm installs repo config files like /etc/yum.repo.d/CentOS-Base.repo. Since the client system can't get out to the internet, any subsequent yum command displays an error about not enough mirrors.
Does any one know of a way to have either Spacewalk or yum exclude the /etc/yum.repos.d/ directory on install of the centos-release package.
It has to be an automated or configurable method as I currently run a manual command on each of the affected systems when I know that rpm is being pushed out. (/bin/rm /etc/yum.repo.d/CentOS-*.repo). I considered a cron job, but that just didn't seem like the best option.
Thanks in advance.
You can tell yum not to use a certain repository:
yum install --disablerepo=centos-base
or you can tell him to only use your repository by disabling all others:
yum install --disablerepo=* --enablerepo=myrepo
The solution I have seen in the past is to configure yum to not use the default location, but instead a different one. For example, /etc/yum.internal.repos.d/. Then anything that happens in the default location doesn't matter.