Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add check for available space on /boot #5

Merged
merged 1 commit into from
Feb 1, 2019

Conversation

bocekm
Copy link
Member

@bocekm bocekm commented Nov 28, 2018

Part of that is removing the leapp-provided kernel and initramfs before the RPM upgrade phase in order to minimize the /boot free space needed.

@bocekm bocekm added the enhancement New feature or request label Nov 28, 2018
@bocekm bocekm changed the title Add checking of free space on /boot WIP: Add checking of free space on /boot Nov 28, 2018
@bocekm bocekm force-pushed the send_msg_w_kernel_filename branch 6 times, most recently from 5716963 to b253339 Compare November 28, 2018 13:01
@bocekm bocekm changed the title WIP: Add checking of free space on /boot WIP: Add check for available space on /boot Nov 30, 2018
@bocekm bocekm force-pushed the send_msg_w_kernel_filename branch 5 times, most recently from d59a834 to 16e6cb3 Compare December 12, 2018 14:53
@bocekm bocekm changed the title WIP: Add check for available space on /boot Add check for available space on /boot Jan 9, 2019
@bocekm bocekm requested review from pirat89 and vinzenz January 9, 2019 13:55
@bocekm
Copy link
Member Author

bocekm commented Jan 9, 2019

The implementation has been done for some time and it's ready for review, I'm missing tests though.

@bocekm bocekm force-pushed the send_msg_w_kernel_filename branch 3 times, most recently from 9b9ed65 to 3268936 Compare January 22, 2019 12:25
@bocekm bocekm force-pushed the send_msg_w_kernel_filename branch from d106785 to eb72d00 Compare January 30, 2019 15:50

def remove_boot_entry():
kernel_filepath = get_upgrade_kernel_filepath()
call([
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we should split this off into its own actor. Because this is failing quite often when there's something unmountable in FSTAB e.g. an NFS share. What you think? (Anyway this is not to block this PR but about kicking of the thinking)
Mainly this is irrelevant to the task the actor does anyway, so it's misleading IMHO.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see you wrote the original actor. Is the mount -a necessary before calling grubby anyway?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vinzenz ping :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bocekm mount -a is what should IMHO happen first thing, but maybe reversed order is better in case mount fails, there wouldn't be a reboot loop :-)

@bocekm bocekm force-pushed the send_msg_w_kernel_filename branch 2 times, most recently from 9ce5044 to 916ab07 Compare January 31, 2019 16:51
@bocekm bocekm force-pushed the send_msg_w_kernel_filename branch 3 times, most recently from e505817 to e635f89 Compare January 31, 2019 18:33
@bocekm bocekm changed the title Add check for available space on /boot WIP: Add check for available space on /boot Jan 31, 2019
@bocekm bocekm force-pushed the send_msg_w_kernel_filename branch 3 times, most recently from ac07a09 to 0657992 Compare February 1, 2019 18:09
- Remove kernel and initrd before RPM upgrade phase to save space on /boot
- Rename actor folders (initrd->initram)
@bocekm bocekm force-pushed the send_msg_w_kernel_filename branch from 0657992 to a844b24 Compare February 1, 2019 19:07
@bocekm bocekm changed the title WIP: Add check for available space on /boot Add check for available space on /boot Feb 1, 2019
@bocekm bocekm requested a review from a team February 1, 2019 19:08
@vinzenz vinzenz merged commit c7f2d16 into oamg:master Feb 1, 2019
@bocekm bocekm deleted the send_msg_w_kernel_filename branch March 10, 2020 09:53
prilr added a commit to evgeni/leapp-repository that referenced this pull request Aug 16, 2022
* Add the initial implementation of third-party integration

* Add vendors' PES events parsing

* Add vendors dir existence checks

* Add a testing deployment script

* Remove references to target system type selector

* Correct the copying in deployment script

* Vendor list handling in PES actor

* Trace-level logging for vendor repomaps

* Repomap additional logging

* Deployment script touch-up: base on cloudlinux branch

* Make PES events scanner accept empty event lists

* Add a test case for empty PES file

* Add missing file to the deployment script

* Add information about the vendors mechanism to README

* Create an additional deployment script for non-CL cases

* Create the vendors.d folder with the generic deployment script

* Update deployment scripts

* Clarifications to the README file related to repositories

* Fix the deployment script not having the correct path

* Implement vendor package signature loading

* Additional logging for the vendor activation

* Accept multiple active vendor lists if present

* Fix the ActiveVendor loading in vendor signature scanner

* Add the new channel-swtich file to deployment script

* Produce custom repofile messages for vendor repofiles

* Remove unneeded FactsPhase sets

* Simplify the package signature check

* Reorder the FactsPhase to make sure signed package scanner receives data

* Target 3rd_parties' version of signed package scanner

* Fix vendor signature comparsion

* Allow for multiple RepositoriesMap messages to be processed

* Changed actor execution order to provide vendor repo data

* Fix the dnfplugin str encode errors

* Revert "Fix the dnfplugin str encode errors"

This reverts commit ddcbbf5.

* Fix the dnfplugin str encode errors (without introducing platform-dependent functions)

* Some clarifications in README about vendors.d

* Move a "successful read" message to debug category

* Switch encode handling to version independent of six version

* Add docstrings to new actors

* Remove script files from the repository

Co-authored-by: Aleksey Petryankin <[email protected]>
dkubek pushed a commit to dkubek/leapp-repository that referenced this pull request May 24, 2023
# This is the 1st commit message:

Fix dead link in checkipaserver actor

# This is the commit message oamg#2:

checkhybridimage: Fix the produce of the report

The actor can produce the report, however the report is never
stored / accepted by the leapp framework as the Report has not been
set in the `produces` tuple. Fixing the actor.

Signed-off-by: Petr Stodulka <[email protected]>

# This is the commit message oamg#3:

Upgrade packit.yaml config to have integration tests

This commit introduces the execution of leapp-repository integration tests as
a packit job.

Signed-off-by: Rodolfo Olivieri <[email protected]>

# This is the commit message oamg#4:

Update packit config to match the leapp-repositoyr tests

Signed-off-by: Rodolfo Olivieri <[email protected]>

# This is the commit message oamg#5:

Add new environment variable to 8.8to9.2

Signed-off-by: Rodolfo Olivieri <[email protected]>

# This is the commit message oamg#6:

Stop mentioning the "releasever" file removal

Do not mention the "releasever" file removal in order to not confuse
users.

# This is the commit message oamg#7:

Fix trace with impossible LEAPP_DEVEL_TARGET_RELEASE

With this change the (pre)upgrade will correctly handle
impossible target release version, no more ugly trace will
be shown.

OAMG-8651

# This is the commit message oamg#8:

Make copr-build functioning again

After some unknown changes around COPR, the building
command and the used COPR configuration file needs to be
updated.

OAMG-8876

# This is the commit message oamg#9:

Add tag in packit.yaml to enable cost metrics collection

Now all tft tests run by packit should be marked accordingly
with a sst-upgrades tag.

OAMG-8892

# This is the commit message oamg#10:

Workaround packit#2010 issue

Looks like tf_post_install_script and environment override does
not play nice together yet, so let's workaround it for now.

OAMG-8892

# This is the commit message oamg#11:

Improve the "checkgrubcore" report message

No action is needed in case Leapp is able to detect the GRUB2 device

# This is the commit message oamg#12:

Update pr-welcome-msg with packit tests info

Let's mention the big leap for leapp officially together with
a command to (re-)trigger tests.

# This is the commit message oamg#13:

Further tune welcome-bot message

- Do not use master, use latest upstream
- Add precise command to request review from oamg-developers

# This is the commit message oamg#14:

Remove note about leapp-ci build

As leapp packages are built by packit now, this is not used
anymore.

# This is the commit message oamg#15:

Fix false positive non-utf symlinks reported

Because of botched up check for python2 valid utf symlinks were reported
as non-utf ones.

OAMG-8629

# This is the commit message oamg#16:

Refactor rootscanner to use library

Also introduce tests for the nonutf symlinks

# This is the commit message oamg#17:

update .pylintrc

# This is the commit message oamg#18:

Set encoding for tests

# This is the commit message oamg#19:

Introduce leapp data in the RPM & repository

In the past it was needed to obtain the data by
* automatic download of data files from RH Insights
  (cloud.redhat.com)
  - which required access to the server & have the system registered
* manual download from the article:
    https://access.redhat.com/articles/3664871
  which required to login to the portal, download the archive
  and install its content manually on the system

Additional problem was with the syncing of data, as because of the
separation of data from the code, people had ensure they are
using the right combination of data and SW manually - in case the
data has not been downloaded automatically from RH Insights.

Having the data in the RPM makes our lives easier so let's install
them to `/etc/leapp/files/` via the package directly.
Set /etc/leapp/files/* as configuration files to ensure that
modified files will be backed up with *.rpmsave suffix as
expected for configuration files. This could be important in case
users manually updated e.g. repomap.json file to reflect their
internal settings of the satellite server.

The complete table how the configuration files are handled during
rpm installation/upgrade/... is here:
    https://www.cl.cam.ac.uk/~jw35/docs/rpm_config.html

Keeping original functionality still available, so if people remove
the files from the system, data can be still downloaded from the
server automatically. It seems it does not make sense, but we could
still use the possibility to download more up-to-date data from
RH Insights.

Configure codespell to ignore .etc/leapp/files

# This is the commit message oamg#20:

Add el8toel9 actor to handle directory -> symlink with ruby IRB.

The `/usr/share/ruby/irb/` directory is a symlink in RHEL 9.

Simply remove the directory to then let the RPM mechanism create the
correct symlink on update.

Users should not expect to ever retain anything in this directory.

# This is the commit message oamg#21:

Enable 8>9 upgrades with FIPS enabled (oamg#1053)

Short story long:
==============

FIPS refers to a set of security standards governing many aspects of how information should be handled by computers and by people. FIPS in context of RHEL typically means FIPS 140, a single document defining rules for the use of encryption and cryptographic services. In essence, it defines requirements for cryptographic modules (e.g. what algorithms can be used, thus preventing the use of insecure ones) manipulating sensitive information.

From the point of view of upgrades there are 5 components that are certified under FIPS: kernel, OpenSSL, GnuTLS, NSS, and libgcrypt. As for the kernel, fips=1 needs to be present on the cmdline in order to enable FIPS in the kernel. Kernel offers a /proc/sys/crypto/fips_enabled virtual file containing the information about whether the kernel has booted with FIPS enabled.

According to FIPS, the userspace components need to verify that they were not tampered with, and thus they have to have some sort of checksum either in a special section of a binary, or in a separate file. The components read /proc/sys/crypto/fips_enabled to know when to switch into the FIPS enabled mode. OpenSSL does things a bit differently, by not including support for FIPS directly but via a special fips.so module. Furthermore, for OpenSSL to check whether FIPS is enabled a configuration file must be present at /etc/pki/tls/openssl.cnf, because the code checking for FIPS is a part of configuration parsing.

As every userspace component has different implementation of FIPS-mode, and a different way for the user to check whether the component believes that the system it is running on has FIPS enabled, there is no straightforward way for us to make really sure that all of the components run in FIPS enabled inside the target userspace container.

Brief summary of changes in the code:
* scanfips: split scanning for fips into a separate actor
* checkfips: inhibit the IPU only on 7>8
* in case of FIPS for IPU 8 -> 9, copy related files into the target container to be able to generate FIPS compliant initramfs
* checkfipsenabled: check for fips in upgrade initramfs (LastTestsPhase); interrupt the upgrade if FIPS is not enabled in the upgrade environment 
* upgradeinitramfsgenerator: refactor library and tests due to FIPS
* create upgrade kernel hmac unconditionallly
---------

Co-authored-by: Michal Hecko <[email protected]>
# This is the commit message oamg#22:

Change the upgrade paths for SAP HANA

 - Drop 7.9 to 8.2
 - Add 7.9 to 8.8, but keep 7.9 to 8.6 as default
 - Add 8.8 to 9.2
 - Drop SAP HANA version check for the target releases >=8.8 and >=9.2
 - Correct actor.py docstring to support ppc64le for 8to9 upgrade (see PR1042)

# This is the commit message oamg#23:

Inhibit unsupported x86-64 microarchitecture RHEL9

As per [x86-64-ABI][1] In addition to the AMD64 baseline architecture,
several micro-architecture levels implemented by later CPU modules have
been defined, starting at level ``x86-64-v2``.

RHEL9 has a higher CPU requirement than older versions, it now requires
a CPU compatible with ``x86-64-v2`` instruction set or higher. Until
now, there was no check for this and the upgrade crashed unexpectedly.
This commit handles this issue and provides the user with a report
explaining the problem.

The CPU Features are gathered using the ``lscpu`` command by way of
using the ``ScanCPU`` actor. The ``ScanCPU`` actor had to be also
modified to provide the required flags. The mapping of CPU Features to
flags provided by ``lscpu`` has been determined by using the
``/arch/x86/include/asm/cpufeatures.h`` file from the linux kernel.

[1]: https://gitlab.com/x86-psABIs/x86-64-ABI.git
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants