After that, the host appears on the hosts list in Katello, but it returns the following warning: No installed packages and/or enabled repositories have been reported by subscription-manager
Also, the Debian host doesn’t show any upgradable packages in Katello, despite of having at least one upgradable package.
I have other CenOs 7 and 8 hosts managed by the same Foreman system. When they return this warning, it usually goes away by starting the goferd service. However, this service doesn’t seem to exist in Debian, or to be available in any packages.
I have just noticed the same thing with my debian10 test client. My client is bound to the Library/Default Organization View. subscription-manager repos on the client shows all rpm repos but no deb repos. The server provides the deb repos on the /pulp/deb/ORG/Library/custom/… URI so it’s there. debian 10 buster repos are set to enabled in the repository set of the client. So they should be there.
I am using simple content access. Maybe that’s the reason?
I think we have different problems. On my side, subscription-manager repos returns the right DEB repos (the ones already configured on the Foreman content view).
The real funny thing is that the Debian host is already working against the repos configured in Foreman, and when queried locally via apt list --upgradable it says one package can be upgraded. But when browsed in the Foreman web console, it says 0 errata, 0 upgrades, etc…
This, combined with the message No installed packages and/or enabled repositories have been reported by subscription-manager makes me think the communication goes only in one direction: from the foreman server to the debian host, but not the other way around.
Seems like the Debian host is missing an agent or some kind of service. I have googled this forum and the whole internet trying to figure out which service it is, or how to install goferd in Debian, without success…
@gvde Simple content access is untested and most likely broken for Debian. It is on our todo list… I am not sure to what extent it is possible to enable simple content access only for RPM, but not for Debian.
@javieitez I believe your issue means that apt-transport-katello is not installed on your Debian host. This should eventually be a dependency of subscription-manager for Debian, but I am not sure for what versions this has already been fixed. For now the workaround is just to install the dependency manually. Once apt-transport-katello is installed, the next APT package action should trigger your Debian host uploading a list of installed packages to Katello.
Too bad. As subscriptions are being deprecated I have set up my new foreman servers with SCA right from the start. As I had to migrate all my clients to the new servers it seemed like the right time to do that.
I’ve found this on /var/log/syslog on the Debian host
Oct 27 10:20:57 debtestvm puppet-agent: Wrapped exception:
Oct 27 10:20:57 debtestvm puppet-agent: Failed to open TCP connection to *********-foreman.*********.local:8140 (Connection refused - connect(2) for "*********-foreman.*********.local" port 8140)
Oct 27 10:20:57 debtestvm puppet-agent: No more routes to ca
Does apt-transport-katello rely on puppet? Do I need to configure a puppet service on the katello server in order to handle the requests from the Debian and Ubuntu hosts?
Certainly, nothing is listening on port 8140 on the katello server.
the apt-transport-katello does not rely on puppet.
The communication is only Client → Foreman querying all needed information (like which repos to enable) and accessing the repos itself. So in theory if you do not use remote execution, you should not need any communication from Foreman → Client in my understanding.
Since the repositories itself seem to work, the problem is probably not in the subscription-manager itself but the upload of the package list. This includes the installed packages, enabled repositories (and maybe facts from the subscription-manager but I am not sure on this). I do not know if there were changes in Katello, which might cause errors. At the moiment I have only a system on 3.1/4.3 to test it but I cannot reproduce an error like that.
Testing with Foreman 3.4 I get an error after installing a package but the traceback is different from yours. If I look at the syslog I get logentries regarding an error with gpgconf because /usr/lib/gnupg/scdaemon seems not to be installed. Can you check if your syslog shows something similar?
GNUPG seems to be running fine in the Debian Host. From /var/log/syslog
Oct 31 09:04:02 ********* systemd: Listening on GnuPG network certificate management daemon.
Oct 31 09:04:02 ********* systemd: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Oct 31 09:04:02 ********* systemd: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Oct 31 09:04:02 ********* systemd: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Oct 31 09:04:02 ********* systemd: Listening on GnuPG cryptographic agent and passphrase cache.
@gvde So I brought up SCA with Debian content internally, and was told that we have done some testing that suggests it does in principle work, so the issues you have hit might be a special case or maybe I was mistaken and they are completely independent of SCA…