I am using Artifactory 5.4.6. I have created a virtual RPM repository, including a local RPM repository and multiple remote repositories.
How can i configure YUM client to use this virtual repository?
Resources Referred:
1. User-Guide
2. Youtube Video
Create file /etc/yum.repos.d/your.repo with content:
[yourid]
name=your private repo
baseurl=https://url.to.your.repository/
skip_if_unavailable=True
enabled=1
There can be more options. See man dnf.conf (they are mostly the same for DNF and YUM).
Related
I have following repo configured
[Artifactory]
name=Artifactory
baseurl=http://myartifactory/artifactory/yum-local/repos/dev/$releasever/$basearch
enabled=1
gpgcheck=0
The above configuration searches rpms in http://myartifactory/artifactory/yum-local/repos/dev/7Server/x86_64/ as well as http://myartifactory/artifactory/yum-local/repos/dev/7Server/x86_64/subdir
How can I force yum to only look at x86_64 and not its subdir?
Can you please check the "RPM Metadata Folder Depth" settings in the RPM repository.This option will informs Artifactory under which level of directory to search for RPMs and save the repodata directory.
For example, if your RPMs are stored under 'fedora/linux/$releasever/$basearch', specify a depth of 4.
Below link for more details:
https://www.jfrog.com/confluence/display/JFROG/RPM+Repositories#RPMRepositories-LocalRepositories
Nexus Repository Manager OSS 3.9.0-01.
I wish to create a 'proxy' Nexus repository that will a replica of the public pypi repository. The other machines can then be configured to point to this Nexus repo. so that a 'pip install' on these machines works even if there is no Internet connection. Accordingly, I created a proxy repository of type 'pypi(proxy)'.
When I browse this repo, there aren't any components/assets but whenever someone does a 'pip install' by pointing to this repo, the package shows up in the interface e.g: pip install --user pyspark --verbose
What I am looking for is to clone/copy all the packages in the PyPI repository at once so that the future 'pip install' refers to this local copy and doesn't go to the Internet every time. Once a day, the local copy should be updated.
Is it possible to do so in Nexus OSS?
What you are trying to achieve is a PyPI mirror repository, not a proxy.
The PyPI proxy repository behaviour you described is correct, because it is a proxy, not a mirror. Nexus Repository Manager does not provide functionality to to create a mirror of another repository.
However, you could try to use a PyPI mirror client (e.g. bandersnatch) to obtain a copy of all packages, then move those files over to your PyPI hosted repository and ask Nexus to reindex the files. Later you would have to periodically repeat the process to keep your mirror up to date.
I am using artifactory with 5.x version and I added http://repo1.maven.org/ as repo1 to my remote repo. But from my artifactory, But I am unable to download some of the artifacts from apache which is from http://repo1.maven.org/maven2/org/apache. How can I allow artifactory to download artifacts from apache folder.
Thanks in advance.....
Quickstart for Endpoints on Compute Engine says
you need to run the Extensible Service Proxy before sending requests
to the API
But it also says
This quickstart works only on Debian. Make sure you create a VM that
runs Debian.
I have an existing GCE VM instance running Red Hat EL 7 that I'm adding this Endpoint to. Where are instructions for installing and running Extensible Service Proxy on it?
FWIW I examined the contents of the Debian package. It appears to be just nginx with custom configs and some extra scripts. If there's no RPM or other way of installing ESP on RHEL7, can I just manually install the contents extracted from the .deb package?
Yes, it should work (not tested). nginx in the .deb package is a statically compiled binary with a custom module that runs fine standalone. Please make sure to place the remaining files (config templates, root CA certificates, start-up script) in the same directories as in the .deb package.
The instructions for installing the ESP are implied in the instructions for installing the Cloud SDK on Red Hat and CentOS, since the endpoints-runtime RPM is available from the same repo as is the SDK.
$ sudo tee -a /etc/yum.repos.d/google-cloud-sdk.repo << EOM
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
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
EOM
$
$ sudo yum install google-cloud-sdk
Note that the ESP installs as nginx, with supporting scripts and config files, that will replace any existing nginx and any files with the same name, which will overwrite any existing nginx functionality (like proxy, cache etc). It might be best to archive any host-specific nginx configs first, then install ESP, then merge old configs into the new ones installed by yum.
I setup a test artifactory server and downloaded some test rpms from a public mirror and then deployed these rpms through artifactory to a local artifactory yum repo (the whole point of this is to test artifactory w/ yum integration). So then I set everything else up and did a bunch of testing so generally speaking the environment has been shown to work (meaning artifactory.repo is config'd correctly and whatever else needed to be done). However. If I "yum install some.rpm" an rpm that is BOTH STORED LOCALLY IN MY ARTIFACTORY YUM REPO and ALSO AVAILABLE IN THE PUBLIC MIRRORS, yum will pull from the public mirror.
How do I deal with this?
Should I deal with this?
Or should I just let yum pull from the public mirror all the time and only use artifactory with yum for my company's rpms?
I mean, what if I want to just build my own repo and not deal with the public mirrors in some cases...?
Is there anything that can "preference" this stuff as opposed to just blowing away the public mirror repo config files in /etc/yum.repos.d/?
Well, it depends on your usecase.
By default Artifactory remote repositories also come with a local cache where they store all downloaded artifacts - so using a local repository to store the same artifacts is redundant.
You can config your yum client to pull from either the remote, local or both if you'd like - it has it's own internal ordering for which one it will access first.
You would mainly use a local repository for cases where you want to be 100% certain only specific versions are used in your build and don't want to rely on what the yum client will choose as an appropriate version, or for cases where you build your own packages for internal use and don't want anyone from 'outside' (outside the team/company whatever) having access to them.