Why this change is needed:
With the new default system in BTRF as Defautl for new instalation
this procedure needs updated.
What this change accomplishes:
. Reflect the diferences between rescue a system in a LVM/BTRF file System.
. Remove Sequence Number Warninig in a debug-dracut-problems.adoc
fix ticket: #316
Note: Please don't push .adoc with Warning Messages is quite anoying
What this change accomplishes:
1. Move PostgreSql to Database Section
2. Remove Tips and Trips in PostgreSQL and move to the following
3. Add manage-sql-server.adoc and add GUI for Mysql/MariaDB/PostgreSQL
4. Add install information phpPgadmin because in fedora 33 is out of repo.
This is now the second time when rpmconf reverted me
google-chrome-stable.repo file back to version where I have `enabled=0`.
It looks like this package generates the repo file in the post scriplet
and does not mention it in the list of installed files, this probably
tricks rpmconf to do an incorrect action. I would love to investigate
further and maybe file a bug for chrome/chromium, but now that I
finished my upgrade I can't look back why rpmconf thought this file
needs updating - scriplet looks like this:
YUM_REPO_FILE="/etc/yum.repos.d/google-chrome.repo"
install_yum() {
install_rpm_key
if [ ! "$REPOCONFIG" ]; then
return 0
fi
if [ -d "/etc/yum.repos.d" ]; then
cat > "$YUM_REPO_FILE" << REPOCONTENT
[google-chrome]
name=google-chrome
baseurl=$REPOCONFIG/$DEFAULT_ARCH
enabled=1
gpgcheck=1
gpgkey=https://dl.google.com/linux/linux_signing_key.pub
REPOCONTENT
fi
}
It was likely some older version of the package. Anyway, I thought I'd
drop a warning note for others, because I accidentally disabled this
repo which left my Chrome on an old version for about a year until it
websites started warning me about an unsupported version. This is
dangerous, my main browser is Firefox but this could be a security
problem for others.
Added sudo to lines where needed
Changed "apachectl reload" to "sudo systemctl reload httpd.service"
Added / to the end of /etc/httpd/conf.d
Technical review completed and is now accurate.
* Simplify list of required packages (and add `grubby`).
* Move Disabled -> Enforcing steps from `changing-to-enforcing-mode` to
`enabling-selinux`.
* In `changing-to-enforcing-mode`, use the correct procedure based on
whether SELinux is currently Permissive or Disabled.
* Add step for ensuring that filesystem is relabeled when re-enabling
SELinux.
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
The kernel functionality that allowed to disable SELinux by changing
/etc/selinux/config is now deprecated and will be removed in F34 [1].
While setting SELINUX=Disabled will still lead to a similar state even
after the removal, it is better to guide users to disable SELinux via
kernel boot parameters, which will actually disable SELinux completely
(as in no SElinux code is executed by the kernel).
[1] https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Use "reboot" consistently, emphasize the immediate no-prompt reboot, mention it's a console terminal, then a second reboot, and clean up step 6 language. This fixes issue #294 and I think is an improvement.
