whois package on FCOS

[shivarammysore]

I have some schema loaders in my code which needs whois. I can't load that package as

$ which whois
/usr/bin/which: no whois in (/var/home/core/.local/bin:/var/home/core/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
$ sudo rpm-ostree install whois-nls
error: "whois-nls" is already provided by: whois-nls-5.5.5-1.fc31.noarch. Use --allow-inactive to explicitly require it.

What is the impact of installing this package with --allow-inactive option? Will I still be able to use whois

[dustymabe]

whois-nls is a subpackage of whois. I think you're wanting to install the whois package itself so try sudo rpm-ostree install whois.

@bgilbert it looks like you added whois-nls in coreos/fedora-coreos-config@d094721. It looks like the whois-nls is not required by any other packages and the description of the package is whois tools messages translated into different natural languages. Did you intend to install the whois package instead?

[shivarammysore]

Clarification: All that I wanted was whois binary which is not available. Hence, my experiments with installing the package itself.

[shivarammysore]

In CoreOS (original), we had systemctl list-units | grep nss services:

nss-lookup.target           loaded active active    Host and Network Name Lookups  

In FCOS, we have:

nss-user-lookup.target                  loaded active active    User and Group Name Lookups

[dustymabe]

Clarification: All that I wanted was whois binary which is not available. Hence, my experiments with installing the package itself.

right, you were just choosing the wrong package. sudo rpm-ostree install whois should get you what you want, assuming you don't hit the base overrides problem (#400)

[shivarammysore]

$ sudo rpm-ostree install whois --allow-inactive
Checking out tree 3477082... done
Enabled rpm-md repositories: updates fedora
rpm-md repo 'updates' (cached); generated: 2020-03-22T02:55:39Z
rpm-md repo 'fedora' (cached); generated: 2019-10-23T22:52:47Z
Importing rpm-md... done
⠁  
Forbidden base package replacements:
  whois-nls 5.5.5-1.fc31 -> 5.5.6-1.fc31 (updates)
This likely means that some of your layered packages have requirements on newer or older versions of some base packages. Doing `rpm-ostree cleanup -m` andResolving dependencies... done
error: Some base packages would be replaced

BTW, rpm-ostree cleanup -m does not help.

[shivarammysore]

More issues: rpm-ostree hangs :-(

$ sudo rpm-ostree upgrade whois-nls 
⠙ Receiving metadata objects: 0/(estimating) -/s 0 bytes... 
Receiving metadata objects: 0/(estimating) -/s 0 bytes... done
Checking out tree 3477082... done
Enabled rpm-md repositories: updates fedora
Updating metadata for 'updates'... done
rpm-md repo 'updates'; generated: 2020-03-22T02:55:39Z
Updating metadata for 'fedora'... done
rpm-md repo 'fedora'; generated: 2019-10-23T22:52:47Z
⠒ Importing rpm-md  52% [██████████░░░░░░░░░░] (6s) 

[shivarammysore]

It is excruciating to upgrade a package and still does not seem to work :-( Without upgrading this package, I cannot install package whois-5.5.6-1.fc31

# rpm-ostree upgrade --install=whois-nls-5.5.6-1.fc31
1 metadata, 0 content objects fetched; 569 B transferred in 1 seconds
Checking out tree 3477082... done
Enabled rpm-md repositories: updates fedora
Updating metadata for 'updates'... done
rpm-md repo 'updates'; generated: 2020-03-22T02:55:39Z
Updating metadata for 'fedora'... done
rpm-md repo 'fedora'; generated: 2019-10-23T22:52:47Z
⠒ Importing rpm-md  52% [██████████░░░░░░░░░░] (7s) 

This is a blocker for me and I am stuck. I have been blowing AWS instances as rpm-ostree does not not even time out and I don't want to screw around trying to debug corrupted rpm database.

[dustymabe]

$ sudo rpm-ostree install whois --allow-inactive
Checking out tree 3477082... done
Enabled rpm-md repositories: updates fedora
rpm-md repo 'updates' (cached); generated: 2020-03-22T02:55:39Z
rpm-md repo 'fedora' (cached); generated: 2019-10-23T22:52:47Z
Importing rpm-md... done
⠁  
Forbidden base package replacements:
  whois-nls 5.5.5-1.fc31 -> 5.5.6-1.fc31 (updates)
This likely means that some of your layered packages have requirements on newer or older versions of some base packages. Doing `rpm-ostree cleanup -m` andResolving dependencies... done
error: Some base packages would be replaced

BTW, rpm-ostree cleanup -m does not help.

Right. You are hitting #400. The latest whois package in the remote yum repos depends on a newer whois-nls package. It's not easy to workaround this which is why we have opened #400 and #401.

[dustymabe]

I don't know why rpm-ostree operations are getting stuck. Is this on the t2.micro systems still?

[dustymabe]

This is a blocker for me and I am stuck. I have been blowing AWS instances as rpm-ostree does not not even time out and I don't want to screw around trying to debug corrupted rpm database.

It is worth pointing out that the way rpm-ostree works you don't have to worry about a corrupted rpm database. You can cancel an rpm-ostree transaction at any point (even losing power) and the machine should be fine.

[shivarammysore]

I am actually using t3.micro instances with EBS storage. If 'rpm-ostree' takes so much time, a notification of some kind is required to communicate to the user if it is doing something or struck. Any idea when #400 will be fixed and released? Thanks /Shivaram

…

On Mar 23, 2020, at 6:15 AM, Dusty Mabe ***@***.***> wrote:  This is a blocker for me and I am stuck. I have been blowing AWS instances as rpm-ostree does not not even time out and I don't want to screw around trying to debug corrupted rpm database. It is worth pointing out that the way rpm-ostree works you don't have to worry about a corrupted rpm database. You can cancel an rpm-ostree transaction at any point (even losing power) and the machine should be fine. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[shivarammysore]

@dustymabe As a workaround, is it possible to provide a 'Whois' binary that can be dropped in - say somewhere on the file system .

This way we can make some progress

[shivarammysore]

Ok. Here is a workaround:

Download Go binary for whois from https://github.com/likexian/whois-go/tree/master/cmd/whois

As /usr/bin, etc is on a Read-Only filesystem, I placed it say, /root/bin and updated PATH settings for my code to work.

[bgilbert]

@dustymabe It's possible that F30 was pulling in whois and F31 doesn't. I only readded whois-nls because I didn't want to drop NLS support as a side-effect of disabling Recommends.

[dustymabe]

We discussed this in the community meeting today.

Chatting with @shivarammysore in the meeting it seems his use case is to do "schema verification of JSON/YAML" using /usr/bin/whois. In the meeting it was pointed out that this is something that can easily be done inside a container and no part of the host really needs this functionality. The suggestion in the meeting was to try to run this in a container as it seems like a simple operation. For example you can currently run ignition-validate (which validates a JSON file) from inside a container to validate an ignition config living on the host like:

cat myconfig.ign | podman run --rm -i quay.io/coreos/ignition-validate -

That being said.. I did just add a PR (coreos/fedora-coreos-config#320) to drop the subpackage whois-nls from the base, which would probably mean you'd have an easier time package layering whois which provides /usr/bin/whois.

[bgilbert]

coreos/fedora-coreos-config#320 merged. I'll go ahead and close.

[dustymabe]

The fix for this landed upstream. It is now pending a testing stream release.

[dustymabe]

The fix for this went into testing stream release 31.20200407.2.2. Please try out the new release and report issues.

[dustymabe]

The fix for this went into stable stream release 31.20200407.3.0.