Erlang is a functional, general-purpose, concurrent programming language and garbage-collected runtime environment built for concurrency, fault tolerance, and distributed application architectures. It is supported and maintained by Ericsson OTP product unit.
In this guide, we will install Erlang/OTP in a Fedora 35 Server/Workstation.
Related Content
- How to install RabbitMQ in Fedora 35
- How to install Erlang on Rocky Linux/Alma Linux/CentOS 8
- How to install Rabbitmq in Rocky Linux/Alma Linux/Centos 8
Prerequisites
You need the following to follow along
- Updated Fedora server/Workstation
- Root access or user with root access
- Internet access from the server
Table of Content
- Updating the system
- Installing Erlang
- Creating Hello world program
1. Updating the system
Let us ensure that our server packages are up to date using this command:
sudo dnf -y update
Let us also install some common packages
sudo dnf install vim -y
2. Installing Erlang
The Erlang package is distributed via Yum repositories on PackageCloud. Install the PackageCloud Yum repository using this command:
curl -s https://packagecloud.io/install/repositories/rabbitmq/erlang/script.rpm.sh | sudo bash
This is the output on my server
$ curl -s https://packagecloud.io/install/repositories/rabbitmq/erlang/script.rpm.sh | sudo bash
Detected operating system as fedora/34.
Checking for curl...
Detected curl...
Downloading repository file: https://packagecloud.io/install/repositories/rabbitmq/erlang/config_file.repo?os=fedora&dist=34&source=script
done.
Installing pygpgme to verify GPG signatures...
rabbitmq_erlang-source 1.2 kB/s | 819 B 00:00
rabbitmq_erlang-source 21 kB/s | 3.8 kB 00:00
Importing GPG key 0xDF309A0B:
Userid : "https://packagecloud.io/rabbitmq/erlang (https://packagecloud.io/docs#gpg_signing) <[email protected]>"
Fingerprint: 2EBD E413 D3CE 5D35 BCD1 5B7C 71C6 3471 DF30 9A0B
From : https://packagecloud.io/rabbitmq/erlang/gpgkey
rabbitmq_erlang-source 364 B/s | 296 B 00:00
Last metadata expiration check: 0:00:01 ago on Fri 12 Nov 2021 07:05:33 PM UTC.
No match for argument: pygpgme
Error: Unable to find a match: pygpgme
WARNING:
The pygpgme package could not be installed. This means GPG verification is not possible for any RPM installed on your system.
To fix this, add a repository with pygpgme. Usualy, the EPEL repository for your system will have this.
More information: https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F
Installing yum-utils...
rabbitmq_erlang-source 3.2 kB/s | 951 B 00:00
Dependencies resolved.
======================================================================================================================================================================================================
Package Architecture Version Repository Size
======================================================================================================================================================================================================
Installing:
dnf-utils noarch 4.0.24-1.fc34 updates 37 k
Transaction Summary
======================================================================================================================================================================================================
Install 1 Package
Total download size: 37 k
Installed size: 23 k
Downloading Packages:
dnf-utils-4.0.24-1.fc34.noarch.rpm 656 kB/s | 37 kB 00:00
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 120 kB/s | 37 kB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : dnf-utils-4.0.24-1.fc34.noarch 1/1
Running scriptlet: dnf-utils-4.0.24-1.fc34.noarch 1/1
Verifying : dnf-utils-4.0.24-1.fc34.noarch 1/1
Installed:
dnf-utils-4.0.24-1.fc34.noarch
Complete!
WARNING:
The yum-utils package could not be installed. This means you may not be able to install source RPMs or use other yum features.
Generating yum cache for rabbitmq_erlang...
Generating yum cache for rabbitmq_erlang-source...
The repository is setup! You can now install packages.
Now we can install erlang from the added repos:
sudo dnf install erlang
3. Creating Hello world program
Create hello.erl
file
vim hello.erl
Add this to the file
% This is a test Hello World Erlang Code
-module(hello).
-import(io,[fwrite/1]).
-export([helloworld/0]).
helloworld() ->
fwrite("Hello from Citizix, Erlang World!n").
Compile it from the Erlang shell. Don’t forget the full-stop (“period“) at the end of each command:
$ erl
Erlang/OTP 23 [erts-11.2.2.7] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe]
Eshell V11.2.2.7 (abort with ^G)
1> c(hello).
{ok,hello}
2> hello:helloworld().
Hello from Citizix, Erlang World!
ok
3>
You have successfully installed Erlang in your system.
Conclusion
Thanks for using this tutorial for installing the Erlang programming language on your Fedora 35 system. For additional help or useful information, we recommend you to check the official Erlang website.
Post Views: 565
I can add the packagecloud repository on CentOS 8, but there are two things that seem to fail:
- There is no
pygpgme
package available in EPEL or the normal CentOS 8 repos, so I have to skip that. - When I
yum install varnish
it uses the version in the CentOS 8@AppStream
which is currently6.0.2-1.module_el8.0.0+19+b2cdb875
.
Is there any official way to get this installed correctly on CentOS 8?
It looks like for #1 at least, the answer is ‘don’t install pygpgme
on centos 8′ in the setup script. For #2 I’m not seeing an easy way to do this.
If I try disabling AppStream, it results in no match for the ‘varnish’ package:
# dnf install --disablerepo=AppStream --enablerepo=varnishcache_varnish64 varnish
Failed to set locale, defaulting to C.UTF-8
Last metadata expiration check: 0:03:31 ago on Mon Jul 6 17:26:46 2020.
All matches were filtered out by modular filtering for argument: varnish
Error: Unable to find a match: varnish
And to confirm, I can reproduce this on a clean CentOS 8 environment with:
$ curl -s https://packagecloud.io/install/repositories/varnishcache/varnish64/script.rpm.sh | sudo bash
$ sudo yum install varnish
It installs 6.0.2 from the AppStream.
It seems like I’m getting farther now on a clean install disabling the AppStream repo:
# yum install --disablerepo=AppStream varnish
Failed to set locale, defaulting to C.UTF-8
Last metadata expiration check: 0:01:01 ago on Mon Jul 6 17:31:40 2020.
Error:
Problem: conflicting requests
- nothing provides gcc needed by varnish-6.4.0-1.el8.x86_64
- nothing provides redhat-rpm-config needed by varnish-6.4.0-1.el8.x86_64
@Dridi — I did that, and now I’m still getting:
Problem: conflicting requests
- nothing provides gcc needed by varnish-6.4.0-1.el8.x86_64
- nothing provides redhat-rpm-config needed by varnish-6.4.0-1.el8.x86_64
Ah… so yum install gcc redhat-rpm-config
made the varnish install work with --disablerepo=AppStream
, but they are coming out of AppStream
which is why dnf module disable varnish
will work.
(Short summary: AppStreams make my head hurt.)
Retesting this in my downstream role, and will close once I can confirm it’s working in a fresh environment.
Indeed, the move from el7’s yum to el8’s dnf is a major step, and the fact that Red Hat is now packaging Varnish as a module makes things both easier out of the box and harder for third party repositories.
Next time, please reach out to a different support channel like the misc mailing list before opening a github issue:
https://varnish-cache.org/support/
I will leave the ticket open since you are planning to close it unless something goes wrong.
@Dridi — Thanks, I didn’t even think about the IRC channel. I’ll try to ask there in the future. I think the main problem was I was looking at the 6.0 release originally which didn’t even have an el8 rpm.
Yeah, the 6.0 series predates el8 but I’m sure that eventually it will grow el8 support.
Open
Issue created Nov 11, 2022 by
Unable to install package for Fedora 36
While #29336 (closed) seems to have been resolved, I’m unable to install gitlab-runner
after executing the script. This is a fresh VM booted from the Fedora Workstation Live ISO available here.
[liveuser@localhost-live ~]$ curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
100 6976 100 6976 0 0 9839 0 --:--:-- --:--:-- --:--:-- 9839
Detected operating system as fedora/36.
Checking for curl...
Detected curl...
Downloading repository file: https://packages.gitlab.com/install/repositories/runner/gitlab-runner/config_file.repo?os=fedora&dist=36&source=script
done.
Installing pygpgme to verify GPG signatures...
Fedora 36 - x86_64 764 kB/s | 81 MB 01:48
Fedora 36 openh264 (From Cisco) - x86_64 1.2 kB/s | 2.5 kB 00:02
Fedora Modular 36 - x86_64 703 kB/s | 2.4 MB 00:03
Fedora 36 - x86_64 - Updates 955 kB/s | 30 MB 00:31
Fedora Modular 36 - x86_64 - Updates 591 kB/s | 2.9 MB 00:04
runner_gitlab-runner-source 331 B/s | 862 B 00:02
runner_gitlab-runner-source 5.3 kB/s | 3.1 kB 00:00
Importing GPG key 0x51312F3F:
Userid : "GitLab B.V. (package repository signing key) <packages@gitlab.com>"
Fingerprint: F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F
From : https://packages.gitlab.com/runner/gitlab-runner/gpgkey
runner_gitlab-runner-source 3.0 kB/s | 3.1 kB 00:01
Importing GPG key 0x35DFA027:
Userid : "GitLab, Inc. <support@gitlab.com>"
Fingerprint: 09E5 7083 F34C CA94 D541 BC58 A674 BF81 35DF A027
From : https://packages.gitlab.com/runner/gitlab-runner/gpgkey/runner-gitlab-runner-4C80FB51394521E9.pub.gpg
runner_gitlab-runner-source 75 B/s | 296 B 00:03
No match for argument: pygpgme
Error: Unable to find a match: pygpgme
WARNING:
The pygpgme package could not be installed. This means GPG verification is not possible for any RPM installed on your system.
To fix this, add a repository with pygpgme. Usualy, the EPEL repository for your system will have this.
More information: https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F
Installing yum-utils...
runner_gitlab-runner-source 630 B/s | 951 B 00:01
Dependencies resolved.
==============================================================================================================================
Package Architecture Version Repository Size
==============================================================================================================================
Installing:
dnf-utils noarch 4.3.1-1.fc36 updates 37 k
Upgrading:
dnf-plugins-core noarch 4.3.1-1.fc36 updates 34 k
python3-dnf-plugins-core noarch 4.3.1-1.fc36 updates 229 k
Transaction Summary
==============================================================================================================================
Install 1 Package
Upgrade 2 Packages
Total download size: 300 k
Downloading Packages:
(1/3): dnf-utils-4.3.1-1.fc36.noarch.rpm 61 kB/s | 37 kB 00:00
(2/3): dnf-plugins-core-4.3.1-1.fc36.noarch.rpm 37 kB/s | 34 kB 00:00
(3/3): python3-dnf-plugins-core-4.3.1-1.fc36.noarch.rpm 147 kB/s | 229 kB 00:01
------------------------------------------------------------------------------------------------------------------------------
Total 153 kB/s | 300 kB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Upgrading : python3-dnf-plugins-core-4.3.1-1.fc36.noarch 1/5
Upgrading : dnf-plugins-core-4.3.1-1.fc36.noarch 2/5
Installing : dnf-utils-4.3.1-1.fc36.noarch 3/5
Cleanup : dnf-plugins-core-4.1.0-1.fc36.noarch 4/5
Cleanup : python3-dnf-plugins-core-4.1.0-1.fc36.noarch 5/5
Running scriptlet: python3-dnf-plugins-core-4.1.0-1.fc36.noarch 5/5
Verifying : dnf-utils-4.3.1-1.fc36.noarch 1/5
Verifying : dnf-plugins-core-4.3.1-1.fc36.noarch 2/5
Verifying : dnf-plugins-core-4.1.0-1.fc36.noarch 3/5
Verifying : python3-dnf-plugins-core-4.3.1-1.fc36.noarch 4/5
Verifying : python3-dnf-plugins-core-4.1.0-1.fc36.noarch 5/5
Upgraded:
dnf-plugins-core-4.3.1-1.fc36.noarch python3-dnf-plugins-core-4.3.1-1.fc36.noarch
Installed:
dnf-utils-4.3.1-1.fc36.noarch
Complete!
WARNING:
The yum-utils package could not be installed. This means you may not be able to install source RPMs or use other yum features.
Generating yum cache for runner_gitlab-runner...
Generating yum cache for runner_gitlab-runner-source...
The repository is setup! You can now install packages.
[liveuser@localhost-live ~]$ sudo dnf install gitlab-runner
Last metadata expiration check: 0:00:52 ago on Fri 11 Nov 2022 03:43:29 PM EST.
No match for argument: gitlab-runner
Error: Unable to find a match: gitlab-runner
[liveuser@localhost-live ~]$ sudo dnf repo-pkgs runner_gitlab-runner list
Last metadata expiration check: 0:01:14 ago on Fri 11 Nov 2022 03:43:29 PM EST.
[liveuser@localhost-live ~]$
- Every run tries to add keys (#20)
- Yum makecache and apt-get update run every Puppet run regardless of changes
- New apt-key is added everytime Puppet is run
Caveats
- Some people use the workflow of releasing a Package to PackageCloud throughout the day, so need every Puppet run to update the metadata for packages, therefore would never have idempotent runs
Possible improvements
- There should be a
$always_update_cache
parameter, turned on by default (as to not break this behaviour for people updating the module) that makes it so that the apt-get update and theyum makecache
(Suggested by @spuder in #12) - For people who use something like run stages for cache updates or only want to use a package that doesn’t change that often, the cache updates should have a
refreshonly
parameter - This refreshonly parameter could be a boolean value, taken from
$always_update_cache
to only run the cache updates if true.
The module assumes direct connection to the internet, which in light of log4shell is a bad idea. It always was a bad idea not to block outgoing traffic in general.
However adding the possibility tp configure a proxy will ease up on this.
Puppet error:
Error: Execution of '/usr/bin/dnf -d 0 -e 1 -y install pygpgme' returned 1: Error: Unable to find a match: pygpgme
Error: /Stage[main]/Packagecloud/Package[pygpgme]/ensure: change from 'purged' to 'present' failed: Execution of '/usr/bin/dnf -d 0 -e 1 -y install pygpgme' returned 1: Error: Unable to find a match: pygpgme
On every puppet run we get something that looks like this.
Notice: /Stage[main]/Profile::Splunk/Packagecloud::Repo[X/Y]/Exec[apt_key_add_X_Y]/returns: executed successfully
Notice: /Stage[main]/Profile::Splunk/Packagecloud::Repo[umich/splunk]/Exec[apt_get_update_X_Y]/returns: executed successfully
Looks like you should check to see if they key is installed first?
Hi!
What is the status of this project? I can see #18 has been open for a while, and the last activity on this project was on the 16th of June last year.
@ice799 are you still actively maintaining this project as part of the packagecloud.io portfolio? Or is this something that isn’t supported anymore?
I’m particularly after the replacement of package { 'apt-transport-https': ..}
with ensure_packages
that currently prevents this puppet module from playing nicely with others.
On Debian, with puppet 3.7.4, using the module outputs this message :
Could not retrieve pygpgme_installed: uninitialized constant Facter::Core
It seems the fact uses rpm command without checking the os.
The API’s Url seems to have changed :
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 404 "Not Found" at /etc/puppet/environments/production/modules/packagecloud/manifests/repo.pp:42
this module should re-use puppetlabs-apt and yumrepo, rather than reinventing their behaviour.
This has the added benefit, that when someone already uses apt to manage their sources, a packagecloud managed repo will not suddenly vanish, because they purge /etc/apt/sources.list*
it should also fix #9.
The gpg key imports should not run every time that the puppet configuration is applied. They should run only if the key doesn’t exist in the keychain.
It looks like a default puppet module (for deb packages) fails with:
Error: Validation of Exec[apt_key_add_myrepo_mypackage] failed: ‘wget -qO — https://packagecloud.io/gpg.key | apt-key add -‘ is not qualified and no path was specified. Please qualify the command or specify a path. at /tmp/vagrant-puppet-2/modules-1/packagecloud/manifests/repo.pp:74
Possible solutions:
- setting global exec path in the end user code: http://www.puppetcookbook.com/posts/set-global-exec-path.html
- adding full path in your puppet code
It’s not a huge problem so feel free to close this issue, but a short info in README or a minor code change could help.
I suggest these changes to make using this puppet module more amenable to pulling into an existing setup.
- change the name of the repository to
puppet-packagecloud
— this will make it easier to find this repository through search engines — it’s only puppetlabs that puts its name as a prefix, the rest of us use ‘puppet’ - the module should be possible to pull down through e.g. librarian-puppet-simple which looks at
<root>/manifests
where you currently have an integration test specification instead of the module’s code
Notice: /Stage[main]/Baseline/Packagecloud::Repo[haf/oss]/Exec[yum_make_cache_haf/oss]/returns: executed successfully
Takes a long time to execute.
Question: This is Yashikha again and thanks for helping me out with the previous issue. Now I am stuck with another error while trying to install python-pip via the yum command. Following is the complete error message.
# yum install python-pip Extra Packages for Enterprise Linux 8 - Next - x86_64 106 kB/s | 206 kB 00:01 No match for argument: python-pip Error: Unable to find a match: python-pip
I did configure the EPEL repo before installing python-pip.
# yum --enablerepo=extras install epel-release ::::::::: Upgraded: epel-release-8-15.el8.noarch Installed: epel-next-release-8-15.el8.noarch Complete!
What could be the issue?
Solution: Fix Unable to find a match: python-pip
Yashikha, the reason why you couldn’t find python-pip in the EPEL repo might be because it may not be called python-pip anymore. To find the exact name of the package, run the below command.
# yum info python*-pip Available Packages Name : python3-pip Arch : noarch Version : 9.0.3 Release : 8.el7 Size : 1.6 M Repo : base/7/x86_64 Summary : A tool for installing and managing Python3 packages URL : http://www.pip-installer.org License : MIT and Python and ASL 2.0 and BSD and ISC and LGPLv2 and MPLv2.0 : and (ASL 2.0 or BSD) Description : pip is a package management system used to install and manage : software packages written in Python. Many packages can be found in : the Python Package Index (PyPI). pip is a recursive acronym that : can stand for either "Pip Installs Packages" or "Pip Installs : Python". Name : python34-pip Arch : noarch Version : 8.1.2 Release : 14.el7 Size : 1.7 M Repo : epel/x86_64 Summary : A tool for installing and managing Python3 packages URL : http://www.pip-installer.org License : MIT and BSD and ASL 2.0 and ISC and Python and (ASL 2.0 or BSD) : and LGPLv2+ Description : Pip is a replacement for easy_install. It uses mostly the : same techniques for finding packages, so packages that were made : easy_installable should be pip-installable as well.
Now you get to know the exact package name. Install it as below:
# yum install python3-pip
user430 2009-08-25 15:47
~0009808 |
Hmmm, not a functionality we use, but yes, pygpgme is not available from CentOS … |
toracat 2010-03-23 15:58
manager ~0011098 |
This is rather an old entry but I thought I should add a note.
At some point in time, there was a centos-release rpm that had the CentOS-Base.repo file containing «repo_gpgcheck=1» in each repo section. So, the fix was to remove the «repo_» from those line. Don’t know where that particular version of centos-release came from ( I suspect during the QA for 5.4 ). |
toracat 2010-03-23 16:00
manager ~0011099 |
Hmmm, from the original submission date, it could not have been the 5.4 QA time. |
Devin Chen 2016-04-13 03:46
reporter ~0026271 |
Just a note:
Follow this step to install virtualbox on centos 5.3: https://wiki.centos.org/HowTos/Virtualization/VirtualBox#head-81de410879b8e7f18a127f638160e036ab99684e # cd /etc/yum.repos.d Then came this error message: Loaded plugins: fastestmirror Remove this line fix problem as toracat said. repo_gpgcheck=1 OS version: # cat /etc/issue |
computology / computology-packagecloud
Goto Github
PK
View Code? Open in Web Editor
NEW
4.0
31.0
69 KB
Puppet module for packagecloud.io
License: Apache License 2.0
Ruby 57.90%
Puppet 39.96%
HTML 2.14%
computology-packagecloud’s Introduction
Table of Contents
- Overview
- Module Description — What the module does and why it is useful
- Setup — The basics of getting started with packagecloud
- What packagecloud affects
- Setup requirements
- Beginning with packagecloud
- Usage — Configuration options and additional functionality
- Limitations — OS compatibility, etc.
- Development — Guide for contributing to the module
Overview
This is the packagecloud.io puppet module which allows you to easily get public and private
packagecloud.io repositories installed on your infrastructure.
Module Description
This is the packagecloud.io puppet module which allows you to easily get public and private
packagecloud.io repositories installed on your infrastructure.
Setup
What packagecloud affects
- The packagecloud module will:
- install apt-transport-https or pygpgme as appropriate for the underlying system
- add the packagecloud.io gpg key for verifying repository metadata
- add apt or yum repos to the system by creating the necessary files under /etc/apt/sources.list.d/ and /etc/yum.repos.d/, respectively
Beginning with packagecloud
Simply install the packagecloud puppet module and you will be able to use the packagecloud::repo resource in your manifests:
packagecloud::repo { 'username/publicrepo':
type => 'rpm',
}
packagecloud::repo { 'username/privaterepo':
type => 'deb',
master_token => 'eae123bca276162f376b9614ba134fa7993624a8de0bb3a2',
}
packagecloud: enterprise users can specify the host and port by setting
server_address
:
packagecloud::repo { 'username/privaterepo':
type => 'deb',
master_token => 'eae123bca276162f376b9614ba134fa7993624a8de0bb3a2',
server_address => 'http://my.internal.server.domain:1234/',
}
If you need to install more than one type of package from the same repository
(for example, gem and deb files from username/publicrepo) you can use the
fq_name
parameter:
packagecloud::repo { 'deb repository for blah':
fq_name => "username/blah",
type => 'rpm',
}
packagecloud::repo { 'gem repository for blah':
fq_name => "username/blah",
type => 'gem',
}
In order to properly use Gem repos, be sure to set your Exec path to include the directory where your gem
binary is located. For example, in your site.pp:
Exec {
path => [ "/bin/", "/sbin/" , "/usr/bin/", "/usr/sbin/" ]
}
Usage
As in the examples show in the above section, you should specify at least type
(which can be either deb, rpm, or gem) and optionally master_token
if the repository is private.
Limitations
Currently supports the following operating systems:
- Redhat Enterprise Linux 5 and 6
- CentOS 5 and 6
- Scientific Linux 5 and 6
- Fedora 14 — 20
- AWS Linux
- Ubuntu 4.10 — 14.04
- Debian 4.0 — 8.0
Development
Pull requests are welcome!
Release Notes/Contributors/Etc
Special thanks to Eric Lindvall for help with puppet.
computology-packagecloud’s People
computology-packagecloud’s Issues
Idempotency Issues
- Every run tries to add keys (#20)
- Yum makecache and apt-get update run every Puppet run regardless of changes
- New apt-key is added everytime Puppet is run
Caveats
- Some people use the workflow of releasing a Package to PackageCloud throughout the day, so need every Puppet run to update the metadata for packages, therefore would never have idempotent runs
Possible improvements
- There should be a
$always_update_cache
parameter, turned on by default (as to not break this behaviour for people updating the module) that makes it so that the apt-get update and theyum makecache
(Suggested by @spuder in #12) - For people who use something like run stages for cache updates or only want to use a package that doesn’t change that often, the cache updates should have a
refreshonly
parameter - This refreshonly parameter could be a boolean value, taken from
$always_update_cache
to only run the cache updates if true.
Missing proxy configuration
The module assumes direct connection to the internet, which in light of log4shell is a bad idea. It always was a bad idea not to block outgoing traffic in general.
However adding the possibility tp configure a proxy will ease up on this.
Error regarding the URL of the API
The API’s Url seems to have changed :
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 404 "Not Found" at /etc/puppet/environments/production/modules/packagecloud/manifests/repo.pp:42
current package contains test logs
Slow execution of `yum_make_cache`
Notice: /Stage[main]/Baseline/Packagecloud::Repo[haf/oss]/Exec[yum_make_cache_haf/oss]/returns: executed successfully
Takes a long time to execute.
Add module to Travis
missing exec path
It looks like a default puppet module (for deb packages) fails with:
Error: Validation of Exec[apt_key_add_myrepo_mypackage] failed: ‘wget -qO — https://packagecloud.io/gpg.key | apt-key add -‘ is not qualified and no path was specified. Please qualify the command or specify a path. at /tmp/vagrant-puppet-2/modules-1/packagecloud/manifests/repo.pp:74
Possible solutions:
- setting global exec path in the end user code: http://www.puppetcookbook.com/posts/set-global-exec-path.html
- adding full path in your puppet code
It’s not a huge problem so feel free to close this issue, but a short info in README or a minor code change could help.
`pygpgme` not available on RHEL8/CentOS8
Puppet error:
Error: Execution of '/usr/bin/dnf -d 0 -e 1 -y install pygpgme' returned 1: Error: Unable to find a match: pygpgme
Error: /Stage[main]/Packagecloud/Package[pygpgme]/ensure: change from 'purged' to 'present' failed: Execution of '/usr/bin/dnf -d 0 -e 1 -y install pygpgme' returned 1: Error: Unable to find a match: pygpgme
expected folder structure for puppet module
I suggest these changes to make using this puppet module more amenable to pulling into an existing setup.
- change the name of the repository to
puppet-packagecloud
— this will make it easier to find this repository through search engines — it’s only puppetlabs that puts its name as a prefix, the rest of us use ‘puppet’ - the module should be possible to pull down through e.g. librarian-puppet-simple which looks at
<root>/manifests
where you currently have an integration test specification instead of the module’s code
Error message for pygpgme_installed on debian
On Debian, with puppet 3.7.4, using the module outputs this message :
Could not retrieve pygpgme_installed: uninitialized constant Facter::Core
It seems the fact uses rpm command without checking the os.
Invalid parameter repo_gpgcheck at /etc/puppet/environments/production/modules/packagecloud/manifests/repo.pp:98
Every puppet run tries to add keys
On every puppet run we get something that looks like this.
Notice: /Stage[main]/Profile::Splunk/Packagecloud::Repo[X/Y]/Exec[apt_key_add_X_Y]/returns: executed successfully
Notice: /Stage[main]/Profile::Splunk/Packagecloud::Repo[umich/splunk]/Exec[apt_get_update_X_Y]/returns: executed successfully
Looks like you should check to see if they key is installed first?
16.04 support?
use apt and yumrepo as dependencies
this module should re-use puppetlabs-apt and yumrepo, rather than reinventing their behaviour.
This has the added benefit, that when someone already uses apt to manage their sources, a packagecloud managed repo will not suddenly vanish, because they purge /etc/apt/sources.list*
it should also fix #9.
Use of ensure_packages over package { ‘apt-transport-https’: ..}
Hi!
What is the status of this project? I can see #18 has been open for a while, and the last activity on this project was on the 16th of June last year.
@ice799 are you still actively maintaining this project as part of the packagecloud.io portfolio? Or is this something that isn’t supported anymore?
I’m particularly after the replacement of package { 'apt-transport-https': ..}
with ensure_packages
that currently prevents this puppet module from playing nicely with others.
Execs should not run every time
The gpg key imports should not run every time that the puppet configuration is applied. They should run only if the key doesn’t exist in the keychain.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.