Bryan Smith wrote:
> I.e., We should only be covering GRUB/GRUB2, and especially the -EFI
> differences, _today_, let alone even back in 2014 when RHEL7 shipped
> with GRUB2-EFI.
> ...
> As I further stated, we should put our resources into covering both
> nVME boot [1d] too
So, just to focus on those sections, plus a few more ... ;)
o [C2v4] "EFI shell, gdisk, parted not included. More appropriate in
LPIC-1 update."
LPIC-1 v4 has already shipped, correct? I didn't see it in there.
[101] [102], and the Wiki just makes the passing mention [C1v4]
So ... might I suggest LPIC-2 v4, and then move to LPIC-1 v5 later?
I'll cover this under the "Lilo" portion, after nVME (NAND SSD like
NVRAM) ...
o [C2v4] "more SSSD"
NAND SSDs using AHCI (whether SATA or PCIe) do _not_ change at all.
Unless, of course, we want to get into all the hardware SFFs like M.2
and various connectors. ;)
AHCI is compatible all the way back to the legacy, 8-bit Winchester
ST506 disk interface of the original IBM PC. It's been moved forward
to the 16-bit PC/AT Programmed I/O (PIO), including with Integrated
Drive Electronics (IDE) and faster PIO modes (including trademarked
ones, like Western Digital's Enhanced IDE, which added master/slave),
then even the generic [PC/]AT Attachment (ATA) specifications that
added then first Direct Memory Access (DMA), 32-bit blocking, etc...
that we now know today with both parallel ATA and Serial ATA (SATA).
The AHCI is just a virtual 32-device "bus" for interfacing with all
that ST506 legacy.
Where NAND SSDs _change_ is when one uses nVME [1].
nVME is _not_ ST506 compatible. That means ...
- It _breaks_ 16-bit BIOS Int13h Disk Services, period, end-of-story
- So ... it won't work on uEFI using Compatibility Support Modules (CSM)
At the same time ... the "3 requirements" ...
- Native 64-bit uEFI Storage Services _with_ nVME support
- Boot loader (e.g., GRUB-EFI) w/64-bit uEFI Storage support
- OS kernel (e.g., Linux 3.3+) with nVME device and commanding support
nVME is 100% _incompatible_ with AHCI and the ST506 legacy, as it's
more like read-only (with buffered write) NVRAM, than platter [1a]
So, "Objectives" ...
1) Know to differentiate between SCSI-like AHCI and nVME
2) Know the Linux /dev/nvme* enumeration for its specific commanding
(again, it's not an AHCI "generic block device" that uses /dev/sd*)
3) Know the 3 requirements to boot
(uEFI firmware w/NVMe, GRUB-EFI, Linux 3.3+ w/NVMe)
o [C2v4] "drop lilo, (consider U-boot and other non-x86 topics)"
My "U-Boot" comment was a "devil's advocate," meaning more Linux
people today know U-Boo than LILO. Heck, they know nVME boot more
than LILO. ;)
I've covered 100% of the above on nVME. Also, for aarch64 (64-bit
ARMv8), GRUB2-EFI covers it little different than for x86-64.
GRUB 2 basics are already covered in LPIC-1 v4. [C1v4]
So ... objectives for GRUB2-EFI (I'll ignore Red Hat's GRUB-EFI
backport to 0.97) ...
1a) Know about the EFI System Partition (ESP), type EF00h, in GUID
Partition Tables (GPT) required for native 64-bit uEFI Storage Boot
1b) Know the ESP is mounted to /boot/efi, and must be a File
Allocation Table (FAT) file system.
Note #1 (not for exam): The uEFI spec states FAT12/16 for removable
media, FAT32 for fixed disk, and most uEFIs implement all for all.
Most OSes support all, but install differently.
Note #2 (not for exam): It can be FAT12, 16 or 32, with various OS
installers creating FAT16 (e.g., Red Hat Anaconda) and FAT32 (e.g.,
Windows x64 Vista/7/2008+). Sometimes the latter is created by
Windows, even if the former exists. FAT32 with 4KiB logical sectors
(not emulated 512B on 4KiB physical, but when logical = physical)
require 260MiB mininum.
Note #3 (not for exam): On GPT disk labels, Windows x64 requires (as
in, to stop writing "hidden sectors" elsewhere) a Microsoft Reserved
Partition (msftres), type 0C01h, of 128MiB, ideally as partition #2
after the ESP, unless the disk is 16GiB or smaller (then only 32MiB).
2a) Know the purpose of the grubx64.efi and shim.efi in the ESP (/boot/efi).
Note #1: I don't think we need to get into secure boot and the MOK
(Machine Owner Key) Manager (mokmanager), which is used by the
shim.efi.
2b) Know the different "targets" of 16-bit BIOS Int13h GRUB v. 64-bit
uEFI Storage GRUB
2c) Know that grubx64.efi is now used for native 64-bit uEFI
_Network_ Services to boot via PXE, instead of PXELinux (part of
SYSLINUX, along w/ISOLinux, etc...).
Network boot in uEFI does _not_ use 16-bit BIOS Int13h Disk Services
"emulation" for character device (byte-by-byte, very _slow_), but a
new, dedicated "block" service that GRUB2-EFI supports (much faster).
Note #1: uEFI Network boot requires a _different_ DHCP option to be
passed than for BIOS-based PXE.
3) Know about the EFI framebuffer (efifb), as 16-bit BIOS Int10h
Video Services, including VESA BIOS Extension (VBE) modes, are _not_
available in uEFI (_no_ vga=xxx).
Details: Although there are some GPU-specific drivers for Kernel Mode
Set (KMS), the "efifb" is the "ultimate fallback" as there is _no_
legacy Int10h Video and _no_ memory mapped console in B0000h as there
is _no_ BIOS and _no_ 20-bit address Real86 mode as uEFI forces 48-bit
addressing (52-bit PAE) "Long Mode" that only allows Protected386 and
Long Mode (no Real86 compatibility, unlike Protected386).
Side Note: This bites _everyone_ in the rear when they try to use
"vga=xxx" modes and try to use "vesa framebuffer" settings, but are
native uEFI booting.
o [C2v4] "introduction (or more) to FreeIPA"
IPA Client is cake, uses SSSD, and is probably ideal for LPIC-1 v5.
IPA Server is also cake, at least before covering replication (which
should be more LPIC-3 w/389 Server).
So, objectives ...
1a) SSSD, which IPA Client/Libraries/Tools use, and are all openldap-libs based
Note: IPA, based on newer 389 w/OpenLDAP Libraries (openldap-libs),
no longer use Netscape Security Services (NSS) from Netscape/iPlanet,
although may require libnss instead of libssl (OpenSSL).
1b) SSSD enforces Root CA Validation and other, Security Best Practices
This includes pam_sss differing from pam_ldap prior, while still based
on openldap-libs. In fact, it's SSS that's just using a new
openldap-libs default, while pam_ldap is based on old code.
Note: This is the #1 issue I see, people using pam_ldap and _not_
having a valid Root CA for their certificates. SSSD then seems
"broken," when their security was broken. An override must be thrown
(cannot remember it from memory).
2a) Understand the "provider" entries and stanzas of sssd.conf
Know what an sssd.conf file looks like, both the ...
[sssd] general stanza section, including the ...
services = (services) entries (at least nss and pam), plus
domains = (provider), and those individual ...
[(provider] stanza sections
Understand how it offers both Kerberos and LDAP providers, with
similar entries to krb5.conf and ldap.conf in their respective
stanzas, but the all important
2b) SSSD entries in NSS and PAM are "sss"
If SSSD has "providers" for both Kerberos and LDAP, include "ldap" and
"krb" in neither /etc/nsswitch.conf nor /etc/pam.d/* files.
Note #1: You still want to configure krb5.conf and ldap.conf for
OpenLDAP Client/Tools and Kerberos k* binaries.
Note #2: This confuses people, but tools like "authconfig" can
provide "legacy" services with some "legacy" options. You want to use
a "pure" SSSD configuration when using SSSD providers for Kerberos,
LDAP, etc...
2c) SSSD also provides a Winbindd replacement
SSSD (1.10+) also provides a Winbindd replacement, meaning you want to
use Winbindd in neither NSS nor PAM, if enabled in SSSD. The SSSD
implementation is actually multi-domain aware, and even works with
IPAv3+ Cross [Kerberos] Realm Trusts (including External AD Forest
Trusts).
Note #1: SSSD's UID/GID enumeration was written primarily by the
Samba team, especially those employed by Red Hat, especially to
enumerate deterministic UIDs/GIDs across multiple AD domains, trees
and forests (no conflicts). The SSSD/IPA approach takes as a
completely different directly from Samba v4 AD Services, the latter
which acts as a member AD server, hence why Red Hat doesn't ship the
Samba v4 AD package, but uses External AD Forest Trusts for
interoperability (IPA outside AD).
Note #2: Long-story-short, POSIX and Windows systems differ in
schema, and by definition, AD and IPA like Windows and UNIX/Linux,
respectively, will always differ in schema, because AD does not allow
schema to differ in the same AD Forest (collection of Domain Trees),
which is why Samba v4 AD only offers Windows schema.
Note #3: As of Windows Server 10, even Microsoft agrees this is a
better approach, and has yanked IDMU (IdM for UNIX), so AD cannot
store IETF2307bis POSIX attributes any more. I.e., Microsoft says to
either enumerate UIDs/GIDs (via SSSD/Winbindd/3rd party, not ideal,
but required when AD doesn't have IDMU), get a costly (CAL-based) 3rd
party option (insert various projects, the ones that do more than the
"free" enuemration), or ... just run IPAv3+ and manage UNIX/Linux
attributes outside of an AD Forest, with cross-trusts with AD
Forest(s). MCPs want the last, they don't want to deal with POSIX,
and Microsoft has listened. I.e., IPA is the future. ;)
2d) SSSD has its own caching in sssd.conf
Do not use nscd or nslcd with SSSD, when SSSD is providing caching of
credentials in its own configuration. SSSD's AD
multi-domain/tree/forest UID/GID enuemration is also more
deterministic than Winbindd's.
3) IPA Services
Understand IPA is managed via web-based administration and its own
ipa-* commands, while being openldap-client and k* command
compability.
IPA Client (and Server) requires SSSD, period, and is cake to setup.
IPA provides ...
- Full DNS zoning for domain, including SRV records (like AD)
Identity (the "I") ...
- LDAP w/IETF RFC2307bis schema (POSIX -- not NTuser as in AD)
This schema is _fixed_, not "variable" like a general LDAP
(this its blessing/curse, don't need to know LDAP, but no flexibility)
- MIT Kerberos v5, including system and user principal keytabs
optionally NFS for NFS4 GSSAPI, aka sec=krb5[ip]
- OpenSSL certificates for systems, and certificate management
- Store of public SSH keys
- Version 3+ (IPAv3+) provides cross-realm trusts
E.g., AD Forest interoperability, even some Global Catalog (GC) support
(I can go into the 5 "roles" of AD Domain/Forest DCs, and how IPA
works with some)
Policy and Audit (the "PA" portion)
- Any SELinux policies
- Any sudoers files
- Any automounter maps
- Several other POSIX maps (and new ones)
- Select logging concentration
- etc...
I'm open to discussing what we can cover in the ipa-* tools, setup and
basic operations, where they differ from openldap-* tools.
o [C2v4] "add xzImage to kernel image names if it ever gets used"
Objective(s):
- Be aware of the "LZMA/LZMA2" compressor, including .xz files and the
xzImage kernel.
The new ".xz" file extension has been appearing as it is just a new
algorithm of the Lempel-Ziv-Markov (LZM) lineage. It has also been
made popular by the open source program 7-Zip, which uses it inside
its archives (like PKZip), instead of on an archive (like tar -- ergo,
.tar.gz) and is increasingly being used by Red Hat and others for its
binary compression and performance -- especially compared to
Block-Wheeler Transform, BWT, popularized by bzip2, which has a heavy
performance/memory footprint cost.
o [C2v4] "update 204.2 (adjusting storage devices) to include NVMe
and AHCI (with IDE/PIO coverage) - make Bryan do it? :)"
Covered above. ;)
-- bjs
[101] https://www.lpi.org/study-resources/lpic-1-101-exam-objectives/
[102] https://www.lpi.org/study-resources/lpic-1-102-exam-objectives/
[C1v4] http://wiki.lpi.org/wiki/LPIC-1_Objectives_V4
"cover UEFI in LPIC-1 instead of LPIC-2
explicitly mention GUIDs w/GPT"
[C2v4] http://wiki.lpi.org/wiki/LPIC-2_Objectives_V4
[1] https://en.wikipedia.org/wiki/NVM_Express
[1a] https://en.wikipedia.org/wiki/NVM_Express#Comparison_with_AHCI
--
Bryan J Smith - http://www.linkedin.com/in/bjsmith
E-mail: b.j.smith at ieee.org or me at bjsmith.me
_______________________________________________
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
