Відео

This is a normal error message to see when working with your system's primary disk. By default, the kernel reads the primary disk's partition table at boot, so the error is telling you that the kernel won't reflect the change you just made using your partitioning utility. You can also verify this by looking at the contents of /proc/partitions (the partitions currently recognized by the kernel). The solution is to use the command: partprobe This command will signal the kernel to re-read the disk's partition tables and after you run it, you should see the change reflected in /proc/partitions as well (so you know the kernel has the most recent partition table loaded).

@@scottmcbrien6535 Will it effect lvms which are available in volume group vg1.

@@ImranKhan-zu6qv This is a hard question to answer exactly because I don't know the setup of your machine. If sdx1 was not a member of any volume groups, it should not affect your LVM setup. If sdx1 was part of a volume group, or even created as a physical volume, you'll want to pvremove it prior to deleting the partition. If you already deleted the partition, use fdisk (or whatever partitioning utility you perfer) and add the partition back. pvremove it, then remove the partition.

"soon". Keep an eye on the Red Hat announcements page: access.redhat.com/announcements That said, there are so many artifacts that are part of a RHEL release, that you'll likely see 8.10 bits being made available through the Red Hat CDN prior to the official release announcement (which is published once EVERY artifact [packages, golden images, virt images, and a variety of other stuff] is complete and verified).

Thank you for watching! - Eric

Hi there, which instructions are you following? The containerized wordpress, or the direct-on-rhel instructions?

Thanks for getting back to me. I’m using the direct on rhel instructions.

@@Nimitz_oceo Well, in that case start by making sure you've got httpd enabled and started, and that the firewall isn't blocking 80/443. You can look for open ports with the ss tool. see if you can see httpd listening on 80 and/or 443. check firewall-cmd to see if firewalld is active and if so what ports it allows.

Generally, if you attach a sos report to a support case, you're sending this level of information to Red Hat today, but on a much more individualized level. Like sos, Insights can have the type of data and amount of data sent reduced through your own configuration changes. I'd suggest starting with this article: www.redhat.com/en/technologies/management/insights/data-application-security There are further links from it to the more precise data as well as changing the configuration to remove data. As to "how many will use it?", don't know. However, things like vulnerability assessment are fast, accurate, and easy with it. Inventory and subscription reporting is easy with it. Even after customizing to remove a lot of the collected metadata, you could still get inventory and subscription use. But I think a lot of the other tools are handy as well. Especially in places like government where you're required to comply with security standards and the like, you can do this today using individual machine level reporting, but Insights aggregates it all to give a much broader population reporting. Of course it requires data to do that, but again, I think the benefit is having that more global management view critical to managing larger populations. The other, IMO more important, questions are what does Red Hat do with the data, is it stored in specific geographies (like we have a sovereign instance in govcloud), etc.

Yeah, we don't do sos data either. I do agree the functionality being demonstrated is awesome. Can't argue that at all. But to your last point, where is that data going and how is it being managed. I can't see a company taking that risk ( on purpose).

Thanks for watching!

Insights can be standalone (included with every RHEL subscription) or integrated with Satellite, if you have one. Or you can mix and match depending on whether your systems are subscribed to satellite or the Red Hat CDN.

@@RedHatEnterpriseLinux Thank you

We usually include a bulleted list of commands in the notes.

As far as I know, the SUID permission on a non-compiled binary file does not "switch the user ID" for the person running it. From your description, it sounds like it was the execute permission that gave your users the ability to execute the script. But there's an easy way to test this. Inside your SUID'd script, run the id command. id will print the user ID of the person running it. If the script is running with switched user ID, this should match the owner of test.sh. However, I suspect that you'll see the username of the person running the script, which would indicate it's not SUID'ing.

@@scottmcbrien6535The permissions seem correct, and if the file "test.sh" resides in the /root directory, a regular user should be able to execute it with the given permissions. However, if a permission denied error is displayed, it's possible that there may be some other factors at play.

@@muhammadshahzad6151 A regular user should not have access to /root, that should be a directory private to the root user (and is permissioned such by default). If you want regular users to be able to run it, maybe put it somewhere like /usr/local/bin. According to the permissions you listed above, user, group, and others have execute permissions, so if it's in a directory they can access, it appears to be executable by all users on the system. Because it's a shell script, the 'permission denied' error may be coming from something being done within the script, especially considering that SUID shouldn't work for regular users on this file as it's not a compiled, binary executable.

There are so many ways to deploy new images, no doubt. I believe this topic will be one we cover in some depth in the upcoming mini-series! - Eric

As 8.6 has only been recently-ish certified, it's going to be a while. 9.0 is certified as well, though if you're wanting to stay on RHEL8, you'll have to wait for NIST to make with the NIST things...

@@scottmcbrien6535 I definitely thought wrong on that.. Yeah it was very recently approved for sure… Unfortunately, so few products (that I use) support REHL 9 that it makes it hard to jump to it.

I don't know what this means? Vagrant is more akin to containers in how you manage and distribute them. As an introduction to managing VMs, yes, we like to keep it simple and approachable. But you can do a ton of complex stuff with the virtualization that natively comes with RHEL if you're willing to write some of your own tooling. When I worked for RH Training & Certification, we used it to manage all the in--classroom systems used by course attendees, including implementing features like snapshotting, rollback, and re-provisioning. Most of that was implemented using LVM and snapshots or merges as the backing storage to the VMs and adjusting the VM definition via dynamic edits and updates to the machine's XML definition. Similarly, you can add networks, NICs, CPUs, update memory, and a ton more either with XML definition updates (and committing those to the backend database) or with direct virsh commands.

Could potentially work, to grant back x to root who could then use chmod to change the mode of the file again. Personally I would re-install core-utils as my solution.

Because it's not really "everyone". When someone interacts with a file, the order of operations is: Is this the owner of the file? Then apply 'user' permissions If not, is this someone in the group that owns the file? Then apply 'group' permissions. The 'others' permissions apply to everyone who is neither the owner nor a group member of the group owner of the file. As a result 'everyone' is not really an accurate description of the people managed by the final field of permissions.

We'll be covering SUID, SGID, and STVX (and filesystem acls, and apparently umask [thanks Nate!]) in our next episode. That said, SUID binaries are generally frowned upon, in fact, most security standards have mounting filesytems with the nosuid mount option as part of their standard. A more modern approach to this problem is containerization. Podman runs rootless (meaning regular people can use it), but within the containers they make, they are offered 'root' shells. In reality, the container host processes still run as their unpriviledged accounts, however inside of their containerized environment, they're given full administrative control. So if someone needs to do something like ... run a webserver or bind a service to a port, they can do that within their container's environment using their containerized root authority. Why is SUID frowned upon? Because you have to account for EVERY.SINGLE.THING that person might do with that application being root. Lets say, for example, you put SUID on the vim executable, thinking that it would allow someone to edit files as root. It works! But it also allows them to use :!/bin/bash and now get a bash shell from which they can do any other activity on the system as root. 😞 The SUID programs that come with the system are very task driven and have been through a ton of hardening, code review, and time-in-use (like the /usr/bin/passwd program). You should be wary of new SUID programs or people asking for you to make other programs SUID.

What part of the process were you interested in hearing more?

@RedHatEnterpriseLinux The container. Interestingly matrix attachment with podman is unique.

Thank you SO much for the feedback!!

For reference, this is on Azure

The good news is that RHEL is RHEL is RHEL. It doesn't matter if you are upgrading on Azure or on a VM. To answer your question, yes, Leapp will automatically update the system to poll the correct repositories. - Eric

Leapp supports disconnected upgrades. However, by default it's going to use the CDN or Satellite defined repositories. If you're trying to do a Leapp upgrade with your own repositories, that can also be done, but needs some additional effort. You could try using the uprade version's iso, like this kbase article shows: access.redhat.com/solutions/7017944

Looks like there's a kbase article with this error message: access.redhat.com/solutions/7004955

Ha, it seems to be the solution to everything, more and more.

@@RedHatEnterpriseLinux 🥺🥺🥺

@@RedHatEnterpriseLinux joke: you say "solution", I hear "we ... shall .... prevail .... (1984)"

There is no standard login and password. The IT landscape is littered with people who built devices with defaults (and users who neglect to change them). In the ImageBuilder build process you can add users to your image, and set their credentials, or add sshkeys to the image, etc. That's how you know how to get into the image afterwards. If you don't want to rebuild the image, though you should just be able to add things to your existing blueprint, you could boot the VM into single user mode and assign a root password to it. You wouldn't want to do this for every machine made from the image though, so better to also fix it in the image.

Indeed! The specialty shops that specialize in data recovery often use this method, by moving the platters to different drive chassis. Personally, I take my disks apart and shred or destroy the platters prior to recycling them.

Two things on this: 1) While there are no technical limitations for upgrading from 7.9 to 9.latest, the leapp tool will only upgrade 1 major version at a time. This gives you the chance to verify that everything still works and there are no issues after upgrading to RHEL 8. Once you've validated your workloads (and hopefully taken another backup/snapshot), then you can proceed with the upgrade. 2) leapp does work offline! You just need to be able to source the packages for the next major version. This can be via #RedHatSatellite or the ISO. Thanks for the great question! - Eric

access.redhat.com/solutions/6970018 There's no direct 7->9 upgrade, you'd do a 7->8->9. This also is somewhat dependent on how closely you're living the 'cloud lifestyle'. If you're in the cattle management business, where you can just re-provision whenever you have an issue with an instance, I'd recommend crafting your workflow for 9, test your apps, etc. Then just start swapping out instances that were 7 for instances that are 9. If instead, you're using cloud as a scalable virtualization, where you do very much care for individual systems, an in-place upgrade on those systems is more appealing.

Great question!

Thanks for watching! As mentioned on the show, in RHEL3 when it was first introduced and RHEL4, when it was first significantly documented, I get it. I didn't start using it until a couple of minor update releases into RHEL4. RHEL 5, it was generally usable. RHEL6+ I think it's generally invisible (largely thanks to the continued improvement to the ruleset in the targeted policy). Also as mentioned late in the show, RHEL9+, you don't want to 'disable' it. You could set the default config to permissive mode, but you'll still get all the alerts about violations in that mode. It just doesn't stop things from occurring that are outside the configured policy. Keep in mind though that folks like the Red Hat Product Security team, when rating CVEs using the modified vendor CVSS score will assume that SELinux is enabled when determining their score for a vulnerability. I think this is the vulnerability Nate and I mentioned re: runc on the show: access.redhat.com/security/vulnerabilities/RHSB-2021-004 With SELinux in enforcing mode, using the targeted policy, the attack vector was blocked for anything other than container_t type files that would be in-scope for a container running, but maybe would not be natively accessible inside of their containerized runtime without a symlink outside. (which is pretty edge-case). But, IMO, saying 'its too hard' could apply to so.many.things. Why not ever use host-base firewalls? Or file permissions? or networks with non-octet bounded network mask descriptions? or systemd configurations? We learn new, and sometimes challenging things because it's a better way to operate our systems, I think SELinux is one of those worth learning.

What types of applications are you running that would compete with the system defaults? - Eric

Thanks for sharing, Scott!

The PAYG systems are by default registered to the cloud provider's Red Hat Update Infrastructure (RHUI), so you remove the RHUI config and repos and then register them to your satellite. Here is a kbase article on the process: access.redhat.com/solutions/3626061

Great conversation, thats Scott and Meme!

Thank you, man. appreciate taking the time to answer. ​@scottmcbrien6535

​@RedHatEnterpriseLinux keep posting such content. They help!

I don't know how you would do this with systemd, but you could configure autofs to automatically mount a CIFS shared directory upon a user login.

Great question! Thanks for sharing!

Billy Holmes responded: Caching tiers are absolutely supported! Here's an example: stratis-storage.github.io/howto/#init-cache-initialize-cache-and-add-block-device-as-cache-device-typically-something-like-ssd

@trozpent Stratis will create a pool out of block devices you provide it. If you send it a hardware RAID, cool. If you give it a software RAID, fine. But you can also give it individual devices. In this lab (www.redhat.com/en/interactive-labs/configure-system-storage-stratis ) we even use individual files in a filesystem to back the stratis pool. That said, there are certainly reasons why you would *not* want to use files in a filesystem to back your stratis pool. There are reasons one would choose a RAID device instead of individual disk devices. For files in file systems, you're now storing files on a filesystem in your stratis pool, which is then reflected in files on a filesystem, which is then stored on a disk. Not having direct access to hardware could slow things down [depending on the I/O and volume of I/O you're doing]. In the case of RAID, you get that physical representation of data across multiple disks to protect from an individual hardware failure. All that said, you can do what you want, but just because you *can* doesn't mean you *should*. 🙂

We are always looking for new places to share our content. Do you have any suggestions?

Does stratis do any redundancy itself, across individual block devices in a pool? Or is that something that has to be done manually? Just wondering about the complete workflow. For instance, in cockpit in an environment without hardware redundancy (I.e. no HW RAID), is it suggested to use mdraid or LVM-RAID first (and which one is preferred?), and then go to Stratis to create pools and go from there? I see a lot of demos mentioning "create pools with multiple block devices" but at the same time it's mentioned "stratis combines multiple technologies including mdadm...". I look at this and think there's some redundancy stuff happening when you just slap a bunch of disks together into a Stratis pool and could see some other folks think this too.

Thank you for the feedback.

Agreed!

We did! At least some basics of configuring it: ua-cam.com/users/livelnXDf95Zubk This episode started with Apache, but then Eric covered the same content for NGINX!

Stratis is storage device pooling technology to run on a single system. It is similar to Logical Volume Management (LVM), but it is less hierarchical than LVM. Essentially, you add your block devices to the pool of storage, then allocate out of that pool for devices to present to your system. Stratis will manage things like thin provisioning your storage device and grow it's in-use storage automatically as data starts to be stored on the device. Conversely, Ceph (now an IBM product) is not just the storage device mangement, but also includes the ability to manage devices across systems into a larger device supported on the backend by networking. Ceph also manages the filesystem components as well, where Stratis would rely on an XFS, ext4, or other filesystem to be put on the Stratis provided device. We have a hands-on lab to provide some experience with Stratis: www.redhat.com/en/interactive-labs/configure-system-storage-stratis

Thank you for the feedback! We are actually releasing a few different types of shorts to see what works and what doesn't!

We are so glad you found it useful!