I’ve come up with these 10 categories of tasks/commands/operations which would render a system un-usable or may cause service disruption or network outage when executed without proper precaution or understanding of the impact of the command and how it works. Most of these commands would also have a forceful execution option which doesn’t even raise a prompt before execution(when run by root or any privileged sudo user). This is in addition to the notorious recursive & forceful file removal command (rm -rf /). I’ve not considered the standard shutdown/reboot commands since these are known and understood by the command itself. Some of the commands would certainly require a root privilege, but the point here is that even as a root user, such commands should never be executed without understanding the details.
[1] Any service stop or restart commands
If any running services are stopped or restarted un-necessarily using either ‘service’ or ‘systemctl’ command then it would impact underlying applications or users connected.
Example: # systemctl stop sshd.service
# systemctl stop network.service
[2] Hard disk partition creation/deletion commands or utilities
Yes, if any disk utilities or commands used which could either remove or create a new partition without proper precautions could render the respective application become unavailable. Most well known commands in this space are “fdisk”, “parted” & “partx”. When someone executes these commands without proper understanding of underlying disk & partitions, then there are possible chances that the execution might corrupt other running/used partitions.
[3] File system creation commands
When a file system creation command gets executed on an already used block device which could eventually end up in re-writing the metadata and existing data would become in-accessible. Hence, such commands would need additional precautions and check before executing.
Example: # mkfs.ext4 /dev/sda1
[4] File system check/scan commands
Though such commands are meant to fix file system integrity, but should not be run unnecessarily on a healthy file system.
Example: # e2fsck -fy /dev/sda1
Otherwise, most of such commands would also provide the dry-run option which could be used first to check integrity of the underlying file system. This causes the operation to be done in read-only mode without making any changes.
Example: # e2fsck -n /dev/sda1
[5] Improper usage of null or random character redirection operations
Any such operation executed accidentally or without much knowledge of how the command works is a disaster since such operations are not reversible.
Example: # echo > /etc/fstab
# dd if=/dev/zero of=/dev/sda1
[6] Network down or "ip address delete" command
Any network down command (if down) (not applicable in RHEL8.x since it is deprecated) or ip address edit/deletion using “ip” command is dangerous when executed on a live/production box which causes the active IP to be in-accessible.
Example: # ifdown eth0
# ip address delete 172.18.1.90/24 dev enp0s3
[7] Changes to /proc or /sys files
As we know, the /proc or /sys file system represents the virtual file system which provides an interface to the underlying hardware sub-system and offers kernel tuning options. So, any changes here are effective immediately.
If any such operation performed without proper knowledge or executed by mistake is considered as destructive and not reversible (not recommended on production environment which is highly loaded/busy which may lead to deadlock):
Example: # echo 3 > /proc/sys/vm/drop_caches
→ The below command causes system to crash immediately and reboot:
# echo c > /proc/sysrq-trigger
→ The below command causes system reboot:
# echo b > /proc/sysrq-trigger
[8] Forceful kill of any running process/threads
Any application or system daemon/process/thread killed forcefully using kill command (similar commands) would cause the respective service unavailable.
Example: # pkill sshd
# kill -9 $(preg sshd)
# kill -9 $(preg sshd)
[9] Deletion of a system/application user account may also cause disruption
Example: # userderl -r sshd
→ This would render any new SSH sessions requests to be blocked, but existing sessions would continue until the session is active.
[10] Improper firewall/iptables rule creation/modification
Yes, any improper firewall/iptables implementation would also cause system lockout or application become in-accessible etc,. Since these rules are parsed from top to bottom whichever rule matches first would get evaluated. Hence, proper precautions needs to be taken when making changes to current rules or while implementing new rules.
--end--
1 comment:
you guys are the best
Post a Comment