Simple way to Boot up CentOS 7 / RHEL 7 in single user mode

The simplest way I found to boot up CentOS or RHEL version 7 is as follows:

• Boot up or reboot your server
• Choose the desired kernel from the Grub boot loader menu by moving with your keyboard's arrow keys
• Press "e" (for Edit ) on your keyboard then scroll down the lines till you see the line that begins with "linux16" word
• Navigate to the end of the line and type “rd.break” at end of the line
• Hold down "Ctrl+x" to boot up that kernel you just edited
• 
  
  
  
  
• Once booting up is finished, you should see a message saying "Entering Emergency Mode" and you should be presented with a shell prompt 
• Remount /sysroot in ‘rw’ mode with the following commands:
• switch_root:/# mount -o remount,rw /sysroot
• switch_root:/# chroot /sysroot
• 
  
  
  
  
• Once mounting the fs is done successfully,  you can proceed with whatever the reason was for booting in Single user mode, like checking/fixing partitions, resetting root's password, disabling/enabling service, etc..

Once you are finished doing what you need to do while in Single User Mode, type exit or hold down the "Ctrl+d" keys to exit that shell, then reboot your system your usual way like shutdown -r now or reboot etc..

That's all.

PowerShell Solution for the trust relationship between this workstation and the primary domain failed

This is one possible solution for the error of 

trust relationship between this workstation and the primary domain failed

Note the solution will be using powershell run as an admin.

First you need to get an idea of when the user computer/workstation domain password was last synchronized. So I ran the following Powershell command:

get-adcomputer -Identity ProblematicComputerName -Properties PasswordLastSet

Which should give you a result like the following. Note the the only entry we care about is the PasswordLastSet field shown in the redbox here:

 

Next step is to reset that machine account password as a domain admin to fix that trust relationship without having to disjoin and rejoin the domain.

This is accomplished by running the following PowerShell command on the affected machine. Note that you have to run Powershell as admin here as well:

Reset-ComputerMachinePassword -Server dc1.your.domain.com -Credential domain\adminusr

Once you click or hit your Enter key to execute the command, you should get a prompt to enter your admin password. So fill-in your domain admin password and click OK.

Assuming all was done correctly, you should be returned to your PowerShell prompt.

So now you need to re-run your the first command to see the result of your command. So wait a minute for the command to synch across your DCs (assuming you have more than one DC) and re-run the command:

get-adcomputer -Identity ProblematicComputerName -Properties PasswordLastSet

and you should get an updated PasswordlastSet field value:

PowerShell Command reference:

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/reset-computermachinepassword?view=powershell-5.1&viewFallbackFrom=powershell-3.0

Error: Rpmdb changed underneath us

Problem:

Ran into this error while attempting to apply a yum update on a CentOS 6 machine to update its kernel packages.

Error: Rpmdb changed underneath us 

The same scenario applies if you get this error as well:

error: can not open Packages database in /var/lib/rpm

Cause:

The problem has to do with corruption in the RPM database files under the /var/lib/rpm directory.

Solution:

• Check for any processes that might be currently running and having a lock on the rpm database and kill them if they exist:
• ps -aufx | grep /var/lib/rpm
• Delete the temporary DB files:
• rm -fv /var/lib/rpm/__*\
• Rebuild your server RPM database using the below command:
• rpm --rebuilddb -v -v

After completing these steps, attempt to run a "yum update" again and it most likely would work fine now. 

It worked for me.

Original Solution Post:

https://www.eukhost.com/forums/forum/technical-support/tutorials-how-tos/18431-how-to-resolve-rpmdb-error-while-update-the-yum-on-server

Postfix fails with (error: postdrop: warning: mail_queue_enter: create file maildrop/randomfilename.xxxxx: Permission denied)

Problem: Postfix delivery fails with error

(postdrop: warning: mail_queue_enter: create file maildrop/randomfilename.xxxxx: Permission denied)


** see note below

Cause:

/usr/sbin/postdrop has incorrect permissions. 
Correct the permissions for /usr/sbin/postdrop are as follows:
# ll /usr/sbin/postdrop

-rwxr-sr-x. 1 root postdrop 180808 Aug 23  2018 /usr/sbin/postdrop

Solution:

Fix permissions with the following:

rpm --setperms postfix
rpm --setugids postfix

Source:
https://access.redhat.com/solutions/1592103

** Note: all of these steps were performed on a CentOS version 6. The same also applies to RHEL version 6

Further troubleshooting:

In order to prepare for this next part, you need to make sure that you have the yum-plugin-verify.noarch installed from your standard CentOS or RedHat YUM repository.

You can figure out the default permissions for whatever file that maybe having a permissions issue on your Linux system.

To prepare for this task, you need to make sure that you have the yum plugin
by doing the following:

• figure out which package provides the file you are troubleshooting.
• On my CentOS 6 system, this can be accomplished by running the command 
• rpm -q --whatprovides /usr/sbin/postdrop which will produce the following output indicating the package name that provided our postdrop file when it was installed:
• postfix-2.6.6-8.el6.x86_64
• Next step is to run the yum verify-all command against the package name to see the default ownership & permissions for its files as follows:
• yum verify-all postfix-2.6.6-8.el6.x86_64 
• The command above will produce something similar to the following output:

• Just please not that this screenshot is not indicative of the problem at hand because the permissions issues were fixed. This screenshot part is only complaining about checksums & mtime values since this postfix install was updated and modified multiple times.

resolv.conf reverts to old DNS entries

/etc/resolv.conf keeps reverting back to its old entries after updating your DNS server list whether manually or via the setup front-end tool for setting up your Network, authentication, services etc on RHEL or CentOS version 5,6,7.

The solution comes from Redhat's KB article entitled "How to make persistent changes to the /etc/resolv.conf?"https://access.redhat.com/solutions/7412

The issue is that DNS servers in /etc/resolv.conf changed after a reboot or network service restart.

If a single ifcfg-file both specifies a nameserver using DNS1 and also gets a nameserver via DHCP, both nameservers will be placed in resolv.conf.

Root Cause:

- From the script /etc/sysconfig/network-scripts/ifdown-post if the "RESOLV_MODS=no" or "PEERDNS=no" is not present in the relevant /etc/sysconfig/network-scripts/ifcfg-* files, the contents of /etc/resolv.conf could get overwritten with /etc/resolv.conf.save.

- /etc/sysconfig/network-scripts/ifup-post script, checks for the presence of "RESOLV_MODS=no" or "PEERDNS=no"

Resolution:

The change in my situation was due to the ifcfg-eth0 file directives DNS1 and DNS2 which lead to modification of resolv.conf

In my particular situation, the solution was to mark the /etc/resolv.conf as immutable with this command:

chattr +i /etc/resolv.conf

to prevent any tool or configuration from modifying it.

For diagnosing the issue, look for entries similar to the following in your /var/log/messages:

Oct 14 12:40:52 hostname NET[22961]: /etc/sysconfig/network-scripts/ifdown-post : updated /etc/resolv.conf
Oct 14 12:40:57 hostname NET[23256]: /etc/sysconfig/network-scripts/ifup-post : updated /etc/resolv.conf