Displaying items by tag: commands
Think you know everything about sudo? Think again.
Everybody knows sudo, right? This tool is installed by default on most Linux systems and is available for most BSD and commercial Unix variants.
Still, after talking to hundreds of sudo users, the most common answer I received was that sudo is a tool to complicate life.
There is a root user and there is the su command, so why have yet another tool? For many, sudo was just a prefix for administrative commands.
Only a handful mentioned that when you have multiple administrators for the same system, you can use sudo logs to see who did what.
So, what is sudo? According to the sudo website:
"Sudo allows a system administrator to delegate authority by giving certain users the ability to run some commands as root or another user while providing an audit trail of the commands and their arguments."
By default, sudo comes with a simple configuration, a single rule allowing a user or a group of users to do practically anything (more on the configuration file later in this article):
%wheel ALL=(ALL) ALL
In this example, the parameters mean the following:
The first parameter defines the members of the group.
The second parameter defines the host(s) the group members can run commands on.
The third parameter defines the usernames under which the command can be executed.
The last parameter defines the applications that can be run.
So, in this example, the members of the wheel group can run all applications as all users on all hosts. Even this really permissive rule is useful because it results in logs of who did what on your machine.
Of course, once it is not just you and your best friend administering a shared box, you will start to fine-tune permissions. You can replace the items in the above configuration with lists: a list of users, a list of commands, and so on. Most likely, you will copy and paste some of these lists around in your configuration.
This situation is where aliases can come handy. Maintaining the same list in multiple places is error-prone. You define an alias once and then you can use it many times. Therefore, when you lose trust in one of your administrators, you can remove them from the alias and you are done. With multiple lists instead of aliases, it is easy to forget to remove the user from one of the lists with elevated privileges.
Enable features for a certain group of users
The sudo command comes with a huge set of defaults. Still, there are situations when you want to override some of these. This is when you use the Defaults statement in the configuration. Usually, these defaults are enforced on every user, but you can narrow the setting down to a subset of users based on host, username, and so on. Here is an example that my generation of sysadmins loves to hear about: insults. These are just some funny messages for when someone mistypes a password:
czanik@linux-mewy:~> sudo ls
[sudo] password for root:
Hold it up to the light --- not a brain in sight!
[sudo] password for root:
My pet ferret can type better than you!
[sudo] password for root:
sudo: 3 incorrect password attempts
Because not everyone is a fan of sysadmin humor, these insults are disabled by default. The following example shows how to enable this setting only for your seasoned sysadmins, who are members of the wheel group:
Defaults !insults Defaults:%wheel insults
I do not have enough fingers to count how many people thanked me for bringing these messages back.
There are, of course, more serious features in sudo as well. One of them is digest verification. You can include the digest of applications in your configuration:
peter ALL = sha244:11925141bb22866afdf257ce7790bd6275feda80b3b241c108b79c88 /usr/bin/passwd
In this case, sudo checks and compares the digest of the application to the one stored in the configuration before running the application. If they do not match, sudo refuses to run the application. While it is difficult to maintain this information in your configuration—there are no automated tools for this purpose—these digests can provide you with an additional layer of protection.
Session recording is also a lesser-known feature of sudo. After my demo, many people leave my talk with plans to implement it on their infrastructure. Why? Because with session recording, you see not just the command name, but also everything that happened in the terminal. You can see what your admins are doing even if they have shell access and logs only show that bash is started.
There is one limitation, currently. Records are stored locally, so with enough permissions, users can delete their traces. Stay tuned for upcoming features.
Starting with version 1.8, sudo changed to a modular, plugin-based architecture. With most features implemented as plugins, you can easily replace or extend the functionality of sudo by writing your own. There are both open source and commercial plugins already available for sudo.
In my talk, I demonstrated the sudo_pair plugin, which is available on GitHub. This plugin is developed in Rust, meaning that it is not so easy to compile, and it is even more difficult to distribute the results. On the other hand, the plugin provides interesting functionality, requiring a second admin to approve (or deny) running commands through sudo. Not just that, but sessions can be followed on-screen and terminated if there is suspicious activity.
In a demo I did during a recent talk at the All Things Open conference, I had the infamous:
czanik@linux-mewy:~> sudo rm -fr /
ommand displayed on the screen. Everybody was holding their breath to see whether my laptop got destroyed, but it survived.
As I already mentioned at the beginning, logging and alerting is an important part of sudo. If you do not check your sudo logs regularly, there is not much worth in using sudo. This tool alerts by email on events specified in the configuration and logs all events to syslog. Debug logs can be turned on and used to debug rules or report bugs.
Alerts Email alerts are kind of old-fashioned now, but if you use syslog-ng for collecting your log messages, your sudo log messages are automatically parsed. You can easily create custom alerts and send those to a wide variety of destinations, including Slack, Telegram, Splunk, or Elasticsearch. You can learn more about this feature from my blog on syslong-ng.com.
Configuration We talked a lot about sudo features and even saw a few lines of configuration. Now, let’s take a closer look at how sudo is configured. The configuration itself is available in /etc/sudoers, which is a simple text file. Still, it is not recommended to edit this file directly. Instead, use visudo, as this tool also does syntax checking. If you do not like vi, you can change which editor to use by pointing the EDITOR environment variable at your preferred option.
Before you start editing the sudo configuration, make sure that you know the root password. (Yes, even on Ubuntu, where root does not have a password by default.) While visudo checks the syntax, it is easy to create a syntactically correct configuration that locks you out of your system.
When you have a root password at hand in case of an emergency, you can start editing your configuration. When it comes to the sudoers file, there is one important thing to remember: This file is read from top to bottom, and the last setting wins. What this fact means for you is that you should start with generic settings and place exceptions at the end, otherwise exceptions are overridden by the generic settings.
You can find a simple sudoers file below, based on the one in CentOS, and add a few lines we discussed previously:
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
This file starts by changing a number of defaults. Then come the usual default rules: The root user and members of the wheel group have full permissions over the machine. Next, we enable insults for the wheel group, but disable them for everyone else. The last line enables session recording.
The above configuration is syntactically correct, but can you spot the logical error? Yes, there is one: Insults are disabled for everyone since the last, generic setting overrides the previous, more specific setting. Once you switch the two lines, the setup works as expected: Members of the wheel group receive funny messages, but the rest of the users do not receive them.
Once you have to maintain the sudoers file on multiple machines, you will most likely want to manage your configuration centrally. There are two major open source possibilities here. Both have their advantages and drawbacks.
You can use one of the configuration management applications that you also use to configure the rest of your infrastructure. Red Hat Ansible, Puppet, and Chef all have modules to configure sudo. The problem with this approach is that updating configurations is far from real-time. Also, users can still edit the sudoers file locally and change settings.
The sudo tool can also store its configuration in LDAP. In this case, configuration changes are real-time and users cannot mess with the sudoers file. On the other hand, this method also has limitations. For example, you cannot use aliases or use sudo when the LDAP server is unavailable.
There is a new version of sudo right around the corner. Version 1.9 will include many interesting new features. Here are the most important planned features:
A recording service to collect session recordings centrally, which offers many advantages compared to local storage:
It is more convenient to search in one place.
Recordings are available even if the sender machine is down.
Recordings cannot be deleted by someone who wants to delete their tracks.
The audit plugin does not add new features to sudoers, but instead provides an API for plugins to easily access any kind of sudo logs. This plugin enables creating custom logs from sudo events using plugins.
The approval plugin enables session approvals without using third-party plugins.
And my personal favorite: Python support for plugins, which enables you to easily extend sudo using Python code instead of coding natively in C.
Conclusion I hope this article proved to you that sudo is a lot more than just a simple prefix. There are tons of possibilities to fine-tune permissions on your system. You cannot just fine-tune permissions, but also improve security by checking digests. Session recordings enable you to check what is happening on your systems. You can also extend the functionality of sudo using plugins, either using something already available or writing your own. Finally, given the list of upcoming features you can see that even if sudo is decades old, it is a living project that is constantly evolving.
If you want to learn more about sudo, here are a few resources:
Linux is fully capable of running not weeks, but years, without a reboot. In some industries, that’s exactly what Linux does, thanks to advances like kpatch and kgraph.
For laptop and desktop users, though, that metric is a little extreme. While it may not be a day-to-day reality, it’s at least a weekly reality that sometimes you have a good reason to reboot your machine. And for a system that doesn’t need rebooting often, Linux offers plenty of choices for when it’s time to start over.
Understand your options
Before continuing though, a note on rebooting. Rebooting is a unique process on each operating system. Even within POSIX systems, the commands to power down and reboot may behave differently due to different initialization systems or command designs.
Despite this factor, two concepts are vital. First, rebooting is rarely requisite on a POSIX system. Your Linux machine can operate for weeks or months at a time without a reboot if that’s what you need. There’s no need to "freshen up" your computer with a reboot unless specifically advised to do so by a software installer or updater. Then again, it doesn’t hurt to reboot, either, so it’s up to you.
Second, rebooting is meant to be a friendly process, allowing time for programs to exit, files to be saved, temporary files to be removed, filesystem journals updated, and so on. Whenever possible, reboot using the intended interfaces, whether in a GUI or a terminal. If you force your computer to shut down or reboot, you risk losing unsaved and even recently-saved data, and even corrupting important system information; you should only ever force your computer off when there’s no other option.
Click the button
The first way to reboot or shut down Linux is the most common one, and the most intuitive for most desktop users regardless of their OS: It’s the power button in the GUI. Since powering down and rebooting are common tasks on a workstation, you can usually find the power button (typically with reboot and shut down options) in a few different places. On the GNOME desktop, it's in the system tray:
It’s also in the GNOME Activities menu:
On the KDE desktop, the power buttons can be found in the Applications menu:
You can also access the KDE power controls by right-clicking on the desktop and selecting the Leave option, which opens the window you see here:
Other desktops provide variations on these themes, but the general idea is the same: use your mouse to locate the power button, and then click it. You may have to select between rebooting and powering down, but in the end, the result is nearly identical: Processes are stopped, nicely, so that data is saved and temporary files are removed, then data is synchronized to drives, and then the system is powered down.
Push the physical button
Most computers have a physical power button. If you press that button, your Linux desktop may display a power menu with options to shut down or reboot. This feature is provided by the Advanced Configuration and Power Interface (ACPI) subsystem, which communicates with your motherboard’s firmware to control your computer’s state.
ACPI is important but it’s limited in scope, so there’s not much to configure from the user’s perspective. Usually, ACPI options are generically called Power and are set to a sane default. If you want to change this setup, you can do so in your system settings.
On GNOME, open the system tray menu and select Activities, and then Settings. Next, select the Power category in the left column, which opens the following menu:
In the Suspend & Power Button section, select what you want the physical power button to do.
The process is similar across desktops. For instance, on KDE, the Power Management panel in System Settings contains an option for Button Event Handling.
After you configure how the button event is handled, pressing your computer’s physical power button follows whatever option you chose. Depending on your computer vendor (or parts vendors, if you build your own), a button press might be a light tap, or it may require a slightly longer push, so you might have to do some tests before you get the hang of it.
Beware of an over-long press, though, since it may shut your computer down without warning.
Run the systemctl command
If you operate more in a terminal than in a GUI desktop, you might prefer to reboot with a command. Broadly speaking, rebooting and powering down are processes of the init system—the sequence of programs that bring a computer up or down after a power signal (either on or off, respectively) is received.
On most modern Linux distributions, systemd is the init system, so both rebooting and powering down can be performed through the systemd user interface, systemctl. The systemctl command accepts, among many other options, halt (halts disk activity but does not cut power) reboot (halts disk activity and sends a reset signal to the motherboard) and poweroff (halts disk acitivity, and then cut power). These commands are mostly equivalent to starting the target file of the same name.
For instance, to trigger a reboot:
$ sudo systemctl start reboot.target
Run the shutdown command
Traditional UNIX, before the days of systemd (and for some Linux distributions, like Slackware, that’s now), there were commands specific to stopping a system. The shutdown command, for instance, can power down your machine, but it has several options to control exactly what that means.
This command requires a time argument, in minutes, so that shutdown knows when to execute. To reboot immediately, append the -r flag:
$ sudo shutdown -r now
To power down immediately:
$ sudo shutdown -P now
Or you can use the poweroff command:
To reboot after 10 minutes:
$ sudo shutdown -r 10
The shutdown command is a safe way to power off or reboot your computer, allowing disks to sync and processes to end. This command prevents new logins within the final 5 minutes of shutdown commencing, which is particularly useful on multi-user systems.
On many systems today, the shutdown command is actually just a call to systemctl with the appropriate reboot or power off option.
Run the reboot command
The reboot command, on its own, is basically a shortcut to shutdown -r now. From a terminal, this is the easiest and quickest reboot command:
$ sudo reboot
If your system is being blocked from shutting down (perhaps due to a runaway process), you can use the --force flag to make the system shut down anyway. However, this option skips the actual shutting down process, which can be abrupt for running processes, so it should only be used when the shutdowncommand is blocking you from powering down.
On many systems, reboot is actually a call to systemctl with the appropriate reboot or power off option.
On Linux distributions without systemd, there are up to 7 runlevels your computer understands. Different distributions can assign each mode uniquely, but generally, 0 initiates a halt state, and 6 initiates a reboot (the numbers in between denote states such as single-user mode, multi-user mode, a GUI prompt, and a text prompt).
These modes are defined in /etc/inittab on systems without systemd. On distributions using systemd as the init system, the /etc/inittab file is either missing, or it’s just a placeholder.
The telinit command is the front-end to your init system. If you’re using systemd, then this command is a link to systemctl with the appropriate options.
To power off your computer by sending it into runlevel 0:
$ sudo telinit 0
To reboot using the same method:
$ sudo telinit 6
How unsafe this command is for your data depends entirely on your init configuration. Most distributions try to protect you from pulling the plug (or the digital equivalent of that) by mapping runlevels to friendly commands.
You can see for yourself what happens at each runlevel by reading the init scripts found in /etc/rc.d or /etc/init.d, or by reading the systemd targets in /lib/systemd/system/.
Apply brute force
So far I’ve covered all the right ways to reboot or shut down your Linux computer. To be thorough, I include here additional methods of bringing down a Linux computer, but by no means are these methods recommended. They aren’t designed as a daily reboot or shut down command (reboot and shutdown exist for that), but they’re valid means to accomplish the task.
If you try these methods, try them in a virtual machine. Otherwise, use them only in emergencies.
A step lower than the init system is the /proc filesystem, which is a virtual representation of nearly everything happening on your computer. For instance, you can view your CPUs as though they were text files (with cat /proc/cpuinfo), view how much power is left in your laptop’s battery, or, after a fashion, reboot your system.
There’s a provision in the Linux kernel for system requests (Sysrq on most keyboards). You can communicate directly with this subsystem using key combinations, ideally regardless of what state your computer is in; it gets complex on some keyboards because the Sysrq key can be a special function key that requires a different key to access (such as Fn on many laptops).
An option less likely to fail is using echo to insert information into /proc, manually. First, make sure that the Sysrq system is enabled:
$ sudo echo 1 > /proc/sys/kernel/sysrq
To reboot, you can use either Alt+Sysrq+B or type:
$ sudo echo b > /proc/sysrq-trigger
This method is not a reasonable way to reboot your machine on a regular basis, but it gets the job done in a pinch.
Kernel parameters can be managed during runtime with sysctl. There are lots of kernel parameters, and you can see them all with sysctl --all. Most probably don’t mean much to you until you know what to look for, and in this case, you’re looking for kernel.panic.
You can query kernel parameters using the -–value option:
$ sudo sysctl --value kernel.panic
If you get a 0 back, then the kernel you’re running has no special setting, at least by default, to reboot upon a kernel panic. That situation is fairly typical since rebooting immediately on a catastrophic system crash makes it difficult to diagnose the cause of the crash. Then again, systems that need to stay on no matter what might benefit from an automatic restart after a kernel failure, so it’s an option that does get switched on in some cases.
You can activate this feature as an experiment (if you’re following along, try this in a virtual machine rather than on your actual computer
$ sudo sysctl kernel.reboot=1
Now, should your computer experience a kernel panic, it is set to reboot instead of waiting patiently for you to diagnose the problem. You can test this by simulating a catastrophic crash with sysrq. First, make sure that Sysrq is enabled:
$ sudo echo 1 > /proc/sys/kernel/sysrq
And then simulate a kernel panic:
$ sudo echo c > /proc/sysrq-trigger
Your computer reboots immediately.
Knowing all of these options doesn't mean that you should use them all. Give careful thought to what you're trying to accomplish, and what the command you've selected will do. You don't want to damage your system by being reckless. That's what virtual machines are for. However, having so many options means that you're ready for most situations.
Have I left out your favorite method of rebooting or powering down a system? List what I’ve missed in the comments!
Source: opensource.com Please visit and support the linux project.
We all know that we use cd command to move from one directory to another. To return back to the previous directory, we use “cd ..” or “cd ” commands. This is how I mostly navigate between directories until I found these trio commands, namely pushd, popd, and dirs. These three commands provides a way faster navigation between directories. Unlike cd command, pushd and popd commands are used to manage a stack of directories. Just enter into a directory and do something you want to do, and “pop” back to the previous directory quickly without having to type the long path name. dirs command is used to show the current directory stack, just like “ls” command. These trio commands are extremely useful when you’re working in a deep directory structure and scripts.
Still confused? No worries! I am going to explain these commands in layman terms with some practical examples.
Use Pushd, Popd And Dirs For Faster Navigation Between Directories
Pushd, popd ,and dirs commands are comes pre-installed, so let us just forget about the installation, and go ahead to see how to use them in real time.
Right now, I am in /tmp directory.
I am going to create ten directories, namely test1, test2, …. test10 in /tmp directory.
As may already know, We can easily create multiple directories at once using mkdir command as shown below.
mkdir test1 test2 test3 test4 test5 test6 test7 test8 test9 test10
Now, let us move to test3 directory. To do so, just type:
To know where you are now, just type:
/tmp/test3 /tmp /tmp
As you see in the above output, dirs command shows we have two directories in the stack now. Do something you wish to do in this directory. Once done, you can go back to your previous working directory using command:
No need to mention the full path of previous directory. If you use cd command, you should type “cd ..” or “cd ” to go back to the /tmp directory. But, using popd command we can instantly move back to the previous working directory. It’s simple as that.
Let us go again to test8 directory. To do so, run:
/tmp/test8 /tmp /tmp
/tmp/test10 /tmp/test8 /tmp /tmp
We’re now in test10 directory, and we have totally 3 directories (test10, test8 and tmp) in our stack. Did you also notice the direction? Each new directory is getting added to the left. When we start poping directories off, they will come from the left as well.
Now, if you want to move to the previous working directory i.e test8 using cd command, the command would be like below.
But it is not necessary though. We can do it more quickly by running the popd command.
/tmp/test8 /tmp /tmp
As you see in the above output, we moved to the previous working directory without having to type full path (i.e /tmp/test8).
Now, let us pop again?
Finally, We came back to the directory where we started.
In this example, I have used just ten directories. So, It may seem it is no big deal. Think about twenty or more directories? Would you type “cd ” or “cd ..” each time to move between directories? Nope. It would be time consuming. Just use pushd command to change to any directory in the stack and move back to your previous working directory using popd command. Also, you can use dirs command at any time to show the current directory stack at any time. You can add a series of paths onto your stack and then navigate to them in the reverse order. This will save you lot of time when you are navigating around stack of directories.
You know now how to effectively navigate between directories without using cd command. These commands comes in handy when you’re working with large directory stack. You can quickly move back and forth through x amount of directories, and these commands are much useful working with scripts too.
That’s all for now. If you know any other methods, feel free to share them in the comment section below. I will be here with another interesting guide soon.