DevNation Live tech talks are hosted by the Red Hat technologists who create our products. These sessions include real solutions plus code and sample projects to help you get started. In this talk, you’ll learn Linux cheat codes from Maxim Burgerhout and Burr Sutter.
In this fast-paced, action-packed session, we will show you numerous Linux tips, tricks, and how-tos, which collectively add up to the cheat codes needed to begin your mastery of the Linux operating system. We'll start off simple, but after a while, we'll dive deep into the rabbit hole. Be ready for arcane shell magic, process management, configuring SELinux, quickly manipulating files, and much more.
Learn more
Join us at an upcoming developer event, and see our collection of past DevNation Tech Talks.
Talk text
Burr Sutter (02:01):
All right. My name is Burr Sutter. I'm coming to you live from Devnexus right now, so if you hear a bunch of noise in my background, that's because I've got a whole bunch of people here. Here, I turned the camera around where you guys can see it. Right now we're actually in session at Devnexus, so there's not a lot of people running around the exhibit hall, but you can see it's a fairly big area. There's over 2000 people here. I did the keynote this morning. We had a lot fun with that, but now we actually have a great topic for you guys today. We're going to be talking about Linux, going hardcore for Linux. I'm excited about it. We have our star here, Max, who's basically worked on our Linux advanced teaching. I've added that link to chat already. Make sure you grab a copy of that. We're going to have more links in the chat show up for you.
Burr Sutter (02:37):
Also keep in mind you can drop your questions into the chat, add them there and we're going to try to queue up as many of them as possible, get to them as soon as possible at the end of the presentation. So Max is going to rattle off all kinds of awesome stuff for us right now. Ready to go, Max?
Maxim Burgerhout (02:51):
Absolutely. Let's go.
Burr Sutter (02:57):
Fantastic.
Maxim Burgerhout (02:58):
Great. Let me share that screen. See how it works. There we go. So my name is Maxim Burghout. I work as a principal solutions architect in Benelux region in the Netherlands. Basically that is, I'm going to show you a lot of Linux-related stuff today. Pace is going to be high, so if one topic doesn't really interest you that much, please stay tuned for a couple of seconds because the next topic might be very interesting for you, indeed.
Maxim Burgerhout (03:25):
Very briefly, me, I'm again, Maxim Burghout. I do a lot of Twittering on @maximburghout at Twitter. I also have a YouTube channel that I use to post stuff on Red Hat products as well, and a blog called 100things.wzzrd.com. In all fairness, the blog has been updated fairly recently, the YouTube channel has not, but I'll try to work on that a little bit more. If you want to reach out to me based on any of the topics I'm going to cover in the next 30 minutes or so, feel free to send me a message through Twitter or an email, but I do not have an SLA for flying. So I'll try, but I might take a little while, especially if it's a lot of traffic.
Maxim Burgerhout (04:01):
What I'm going to be about today is I'm going to talk about elevated privileges. I'm going to talk about job control, history management, a little bit of SELinux, little bit of ACLs. I'm going to show you what a heredoc is. I'm going to look at networking and we're going to look at management of services with systemd. I'm going to try and mix some advanced topics and some more entry level topics together, so I hope I'll have something for everybody.
Maxim Burgerhout (04:25):
So let me switch to my terminal real quick and we'll dive right in it. So here we have a pristine RHEL 8 machine. I'm going to pretend I'm a developer right now and I'm going to pretend I'm a developer that wants to deploy a little PHP app on Apache here. Now as you might know, you can install packages on RH with the yum commands. So I'm going to go yum install httpd, php, php-gd (the image library) and php- (I think Postgres is pgsql).
Maxim Burgerhout (04:53):
You don't have to use DNF which the new package manager on RHEL 8. You can just using yum. It will result in burning the same binary and if I hit this command, the observing user might already notice this is not going to fly because the yum command actually needs elevated privileges on Linux to install packages. Now I could hit up at this point and hit left a million times all the way back to the beginning of the line. That is not really efficient. I could also hit up and then go Ctrl+K back to the left, or Ctrl+Left arrow back to the beginning. That's not really efficient either.
Maxim Burgerhout (05:25):
I could even do Ctrl+A and go back to the beginning of the line and Ctrl+E, go back to the front, but none of those options are as efficient as going just sudo and then hit exclamation mark (!) twice which is going to execute the previous command but then prepend it by two. This on its own is not going to work either because you might've noticed I made an intentional typo there. Oh, because I wanted to show you a little nifty nifty trick that you can do with your history in Linux, which is by correcting your previous command and I could go carrot (^), which is the triangular character I'm typing there and just go, I want to replace this by this.
Maxim Burgerhout (06:07):
And if I hit Enter again this command line is actually going to work and it's going to install Apache and PHP and some other stuff. As that is running, which is just going to take about 20 or 30 seconds or so, I want to just briefly mention that I'm doing stuff as sudo all the time. I'm not doing this as root because I consider running as root all the time the anti-cheat. This is actually making your life harder instead of easier because running as route all the time is going to teach you nothing about the actual requirements your applications are going to have when you bring it into production.
Maxim Burgerhout (06:40):
So do not do everything as root. Set yourself up for a sudoer account and use that if you notice that your normal personal account does not have enough privileges. Now as a little cheat again to edit the sudoers file, I would suggest you use sudo visudo. Just don't go using VIM or Emacs or whatever it is on the plain sudoers account, on the plain sudoers file because that has no syntax-checking in there. You could just edit the file, save it, you can lock yourself out of the root account that way and that is very, very inconvenient, as you might imagine.
Maxim Burgerhout (07:15):
If you use visudo as I'm doing right now, you actually get syntax checking of your sudeoers file for free. So I could take out my cloud-user line here and I'm going to comment out that line and I'm going to comment out this line and I'm going to add a comma here. That comma has a syntax error. Now look what happens when I save this file. It's going to give me an error message. It's going to tell me, you have a syntax error line 110, which is directed to the comma. Now what do I do now?
Maxim Burgerhout (07:41):
I can either edit this file again, save it without changes or save it with the change I just made and that would basically lock me out of my sudoers permission. So that's not something I want to do. I want to edit this again, go back to line 110, I'm already there. Take away that comma, save this file and now it's actually edited in the correct way and go sudo -L and I can see all the permissions I have.
Maxim Burgerhout (08:03):
So don't you run your commands as root all the time, it's actually going to make your life harder. Now, you might be familiar with the fact that Linux has a history command for various shells Linux is equipped with. I already showed you the correction of the previous command with a carrot, a notation. You can also just take a look at your history by running history and you will see that all of the commands I've just previously entered are listed there and I can run one of the previous ones by going exclamation mark and then eight, for example will show who execute the sudo -L command again.
Maxim Burgerhout (08:38):
Now if I just go ls, ls, ls, ls, ls in this empty directory and run history, it will see that the ls command is only added to the history file once and that is because we have this environment variable called HISTCONTROL that is set to ignore dupes, ignore direct exact duplications of command. So it's going to only add the ls command to my sudo or to my history file just the single time.
Maxim Burgerhout (09:02):
But you might notice that I have ls here in twice and if I would go ls, echo, whatever echo, ls echo, it's actually... ls is actually in there a bunch of times, which is not really that convenient because I want to use my history file to have the history of as many useful commands as I can have and not a repetition of the commands I have to basically give 1000 times a day.
Maxim Burgerhout (09:29):
So in order to make my history ignore all of the duplications I have in there over time, so not just direct duplications, but duplications over time, I can actually set the HISTCONTROL command to erase those. If I do erase those, and I'll check my history. There's a couple of... It mentions ls in there. If I go ls once more and run history, you will see that the previous ls instances are now gone, so you get more useful history and less clutter.
Maxim Burgerhout (09:57):
Now you all might have had that situation in which you have to enter a command that is kind of secret because it has your password with a password flag or something like that. And this is going to add... This is going to end up in your history as well. So you'll know this command, right? It's a secret command and it has a password flag as my secret password is in there.
Maxim Burgerhout (10:14):
Now if I execute this, it's going to end up in plain text in my history file. That is probably something I do not want to have either, so if I take that HISTCONTROL command again and add colon, ignore, space (:ignore ) to this, you can actually execute that secret command pretty... Well, not completely safe. There are better ways to do this, but I just want to show you this. My secret password like that and you will now see there's an error because the command doesn't exist. It doesn't even matter.
Maxim Burgerhout (10:43):
If I run history here, you will see that the secret command does not end up in my history file because I presented it with a space and I have to ignore space [inaudible 00:10:51] over there. Now if you want to have this HISTCONTROL environment variable enabled all the time, every time you log into your Linux machine, you'll just edit your .bashrc file and you go to the bottom. That's an export there. Drop that little line and you save it. You log back in and it's enabled every single time. The .bashrc is the configuration file for your shell.
Maxim Burgerhout (11:15):
Now there's one more thing that is interesting to tell you about history. If you hit Ctrl+R, you can actually search backwards in your history. So I would go HISTCONTROL and it could actually see... Hit Ctrl+R again, I can actually scroll through all of the occurrences of HISTCONTROL in my history. This is reverse search as you might see here in reverse, and there's actually a forward search as well, which is mapped to Ctrl+S instead of Ctrl+R (R for reverse search, S for search), but S is also meant to pause my shell.
Maxim Burgerhout (11:41):
So if I hit Ctrl+S here I can type whatever I want. It's not going to end up in my shell until I hit Ctrl+Q. So if you have a shell that seems unresponsive, try and hit Ctrl+Q, because that will un-pause your shell and maybe you've got your shell back. So just a little tip right there. Let's move over to something we call job control. So let's do a ping of www.redhat.com, right there. Ping on Linux is not going to end. So if I leave this running it's going to just run on basically until the end of time.
Maxim Burgerhout (12:16):
And if you want to pause this command for whatever reason, I'm going to hit Ctrl+Z. Able to see that it's now stopped and I got a job ID there. So this command is non-stop. I can hit jobs, get the same output as there. Job number one is stopped and it's pinged www redhat.com. I think, so you can take this command back into foreground by running fg and my ping command will continue running and we'll just keep... Basically continue where the previous iteration of this, the previous run of this command left off.
Maxim Burgerhout (12:45):
If I hit Ctrl+Z again or Z. I don't know if your guys are American or English or maybe some other language, but Z or Zed, and I can hit bg for background. And now this command, the ping command will continue running again, but I also get my shell back. Now the output of the ping command is going to just drop through my shell right there because this is a demo. But you can get a bit of a feeling of what kind of use cases this could be useful.
Maxim Burgerhout (13:11):
I can hit foreground again, take this back into the foreground and hit Ctrl+Z to put it in pause mode or stop mode again, suspend it. I could, and I'm not going to do that right now, I could disown this by the disown command and then I just can log out of this machine and the ping command will keep on running in the background. I'm not going to do that right now. Or I could kill the job by just going %1, I'm going to kill the job that has already run. Put it back in the foreground, and I already killed it. So, okay, sorry. Sorry about that. A little confusion there.
Maxim Burgerhout (13:41):
But as you see, I can kill the job that is in the background by going %1 is going to terminate the job in the background so I don't have to look up the job ID or whatever, the process ID or whatever. I can just kill it by giving it, giving [inaudible 00:13:55] kill the job ID of the job. Now as you might've noticed, I'm not doing kill -9, and I see a lot of people going kill -9 everything. Kill -9 is like shooting a cannon where you would have sufficed with a peashooter. Kill -9 basically tells your program to die instantly, which is fine for a ping, but if you're killing -9 the database, your database is going to die without writing to disk, which is probably not what you want.
Maxim Burgerhout (14:23):
So to try and send programs the kill signal first without -9, and if that doesn't work, you can always revert to adding the -9 [inaudible 00:14:31]. Don't just go killing -9 everything. You're going to end up in a world of pain. So much for job control today.
Maxim Burgerhout (14:39):
I also want to talk about SELinux for a while. SELinux is something that is extremely useful in terms of security. Some people find it a little bit confusing. So I'm going to just show you a little bit about how SELinux is not scary and how SELinux can actually be manipulated fairly easily if you know what you're doing. So I just installed Apache, right? Now, let's just, for sure, let's just make sure that Apache can actually be started. So I'm going to go systemctl start httpd. Systemctl, the command you start and stop demons with on RHEL. I'm going to start that and am going to run the status command and it will give me a lot of information about this process.
Maxim Burgerhout (15:17):
It is actually running right now. It will not run by default because the vendor preset is disabled. So this program does not run by default. If I install Apache and reboot my machine, it will not start it by default. If I want to have it start by default, I need to do enable httpd. So if I do enable, get your status again we'll see it's now enabled where it was previously disabled. And it's listening on port 80 right now and that's interesting because my application is weird and I really want to run this on port 8001.
Maxim Burgerhout (15:47):
Well let me stop this for a bit. Oh, wait, Nope, let me do it... Sorry, one thing more. If we want to check out what kind of SELinux context, my httpd, my Apache process, httpd is running at, I go ps-efZ (zed) or Z and I'm going to grep for Apache here, https and it will show me that my Apache process is running with the httpd SELinux context. This is important for later on. I'll show you what I'm going to do with that.
Maxim Burgerhout (16:16):
Now I'm going to stop Apache for a while because we're going to change the port and we're going to edit the Apache configuration file and make Apache run on port 8001. In order to know which file I need to edit, I can just run rpm -qc plus the name of the Apache RPM, and it will tell me what configuration file we're into. I can also do -qd, by the way, just to note in the documentation, but I need the configuration files. So I'm going to show you the configuration file and the configuration... And the main configuration file for Apache is this one. I'm going to edit that with a sudo -e because I don't want to go figuring out what my favorite editor for today is. I'm just going to choose my default.
Maxim Burgerhout (16:56):
Sudo -e starts my editor in brute mode, so in my case it's vi. Starting that up, I'm going to find the listen directive, so the listen directive tells Apache what port to listen on. I'm going to change that from 80 to 8001, okay? And hope you guys are all still with me. I can't see you guys nodding or whether or not you're looking interested or bored, but I'm going to assume this is interesting for everyone.
Maxim Burgerhout (17:20):
I'm going to try and start Apache again and you'll see if this failed. You're like, "Why is this failing? Why is this failing?" And you're going to run the status. And status tells me Apache could not bind to address 8,001, and that is actually pretty understandable if you take into context that this system is actually running SELinux. And you're going to run the status, and sestatus tells me that SELinux is enabled at this moment and we can actually take a look at what kind of ports SELinux knows about. Manage, list my ports.
Maxim Burgerhout (17:54):
And every port in SELinux has a label and SELinux basically tells the Linux kernel which application can bind on which port. So basically SELinux knows these are lists of Apache ports. I'm going to list all the ports and then grep for 443. This is a list of Apache ports right there and the Apache process that runs with the httpd content, HTTPD_T, SELinux context and binds to port 80, port 81, port 443, port 8008, port 8009. But as you can see port 8001 is not in here. So we need to make SELinux aware of the fact that we want to have Apache run on port 8001.
Maxim Burgerhout (18:35):
It's the only thing we need to do and after that everything's going to be fine. We'll be able to retain the security that SELinux gives us and still run our application on port 8001. The way we make SELinux aware of the fact that we want to allow Apache to run on port 8001 is we're going to semanage, we're going to add a port and we're going to add a port to this side here, Apache SELinux ports type. We only want to do this for the QCP because Apache runs on QCP connection and we want to do that with port 8001. So run this, it takes about a second, and then we run desk command again.
Maxim Burgerhout (19:15):
We're going to check port 443. And as you can see 8001 is now in the list of ports that are labeled Apache. The only thing you need to... Just relabel that that port with http_port_t and now I can actually start Apache on that port. Go to systemctl, start, start Apache and now it's running and you will see it's now running on port 8001.
Maxim Burgerhout (19:41):
Now if this all was a little quick, the slide at the end of the presentation today, I have to link to a whole lot of documentation around SELinux and you can just read this back in your own time, but I just wanted to show you, SELinux is not scary. It's actually pretty useful. It's a very, very good security feature that is in RHEL and it is not easy to manipulate, manipulate, again, if you know what you're doing.
Maxim Burgerhout (20:03):
One more thing I want to talk about SELinux, just in the context of SELinux. As you might be aware, Apache and PHP often run applications that need to connect to a database (MySQL, PostgreS, whatever). Those applications, those databases might run on the same machine or they might run on a different machine. By default, SE Linux will disallow Apache to reach out to a database that is running on a different server. That is because of security. We don't want Apache to do stuff that we are not explicitly allowing it and this is something we need to explicitly allow Apache to do.
Maxim Burgerhout (20:40):
SELinux knows the concept of a boolean and we can basically list all of the booleans that we have on this system and basically booleans are toggleable pieces of SELinux that allow applications to do a certain thing. In this case, I'm just showing you the all of the booleans that are available for SELinux and then grepped for http, which are the booleans that have to do with Apache. You will see that there is one right there. It says httpd can network connect to a database. By default, this is off. So SELinux prevents applications running in the context of Apache to connect to databases that are on a different system.
Maxim Burgerhout (21:16):
If I want to flip this to on, and just go... That's get SELinux boolean and I'm going to copy that real quick because it's long, and I'm going flip to to on. That's it. My application will now be able to connect to database. [inaudible 00:21:32]. And there we are. It's now flipped on. If I want to make this permanent over reboots, I've just executed this again with the -P flag for permanent and I can reboot as many times as I want right now. Apache will still be able to connect databases that are onto a different system.
Maxim Burgerhout (21:51):
Now, we have an Apache running on port 8001 on this system. 8001, this is the output of the test page of Apache on a Red HatEnterprise Linux 8 machine. Let's go to the directory that we write our application files into /var/www/html. I cannot, as cloud-user, not write in here because this directory is owned by root. So what we want to do is we want to set an ACL, access control list in this directory.
Maxim Burgerhout (22:21):
And what we do to make that happen, it's going to run set file ACL. Going to modify [inaudible 00:22:26]. Modify an ACL for a group, the group is cloud-user because that's my... I'm going to get myself read, write, and execute permission for this directory and that's basically it. And because I want to be able to read and write new files that are written in this directory as well, I'm going to make the default ACL be the same.
Maxim Burgerhout (22:43):
And now I actually am able to write in this directory. And as you can see we have all of the files and the directory itself now have the plus sign (+) appended to it in the output of ls. Again, there we go. It wasn't there before, it is there now. That indicates there's an ACL in this directory. So if they'll get file ACL on foo it gives me that I actually have read and write permission on this file. So that's pretty useful because we want to write an index here.
Maxim Burgerhout (23:11):
Now, the index I'm going to do, I'm going to write that index, index that HTML with a concept called heredoc. A heredoc is a concept in Linux that is often used in scripting and you've probably seen one before. They look like this. Basically they start with the cat command (concatenate) and then they basically a random word, an EOF and a file is often used for this because it's not often used in everything that comes next. And we're going to write all of this out, into index.html.
Maxim Burgerhout (23:40):
The moment I hit Enter, everything I write from this point on will be written to index.html. This is a DevNation live broadcast by Burr and Maxim. There you go. This is very nice. Whatever. Then I write EOF, end of file, this indication that I'm done writing. Hit Enter and my shell will return. I will now have an index.html file here, and then I'll curl localhost... Oh, missed one. Localhost on port 8001. It will see the output of the index.html I've just written. I hope that is useful. I'll use heredocs all the time when I'm writing bash scripts, so if you guys write bash scripts a lot and if you want that bash script to at some point write some data to a file, heredocs are your friend.
Maxim Burgerhout (24:32):
So let's move on. As you might remember, I want to talk about this a little bit too. I'm not going to spend a lot of time talking about systemd, even though it is an awesome feature. But you might remember the output of the systemctl status httpd, that it shows you the memory usage by this process at this point in time. Now, let's pretend I'm sharing this system with ton of other applications and I want to limit my Apache web server to, let's say, 256MB of RAM. The way to do this is by going systemctl edit httpd.
Maxim Burgerhout (25:08):
This is going to give me an editor in which I can override certain aspects of what we call the unit file in systemd. The unit file basically... Let me show you one here real quick. It looks like this. This is the Apache unit file. There's a lot of comments here at the top. Unit file describes the dependencies of the Apache service, which services have to be started first, where the documentation is, what kind of service this is, what the start command is, the reload command is, how do we kill it, does it have a private tmp directory, et cetera, et cetera.
Maxim Burgerhout (25:41):
I don't want to override this whole file because when the Red Hat package maintainer for Apache changes something I actually want to get that change. Maybe this is a very silly thing to do for... Actually, I can reload and we might change it in the future, in a future release of the Apache package. And if I just override the whole file, then I don't get that change.
Maxim Burgerhout (26:00):
So what I want to do is create what we call the drop-in. And a drop-in is basically a little file that overrides only parts of the unit file, that's just the Apache unit file. Again, we do that by going sudo systemctl edit (that goes over there) edit, HTTPD. It's giving me an empty editor. I can now add a directive that override certain aspects of that unit file. In this I'm just going to add a line to the unit file. I'm not going to override anything. I'm going to add a memory limit, limit of 256MB. There we go. I save it. Now check what happens to my running Apache unit. It now has a memory limit of 256MB. It didn't even restart because it started seven minutes ago, but through the drop-in in that right there, that's my drop-in over there. It's the file I just created.
Maxim Burgerhout (26:57):
You don't have to remember where you need to create this. If you do your systemctl edit httpd, it will automatically create it in the right location. Through the contents of that little file over there, I now have created a memory limit for this service and you can override various different aspects of your systemctl demons through this way as well.
Maxim Burgerhout (27:17):
Now, final thing, because I think we're almost out of time. One more thing I want to show real quick. We know that Apache is now running on port 8001. But if we want to know what other services are running on this system, we can use the netstat command. You can also use the ss command, which is fairly newer and has a slightly odd name. So I'm going to use netstat and now I'm going to teach you something. I'm from Holland, the Netherlands and if you're thinking Netherlands, you think about clogs and tulips, right?
Maxim Burgerhout (27:42):
So I'm going to pass a couple of parameters to the netstat command and they will form the Dutch word for tulips. So you will never forget the Dutch word for tulips ever again. I want information about any open TCP connections, UDP connections. I want to see listening sockets. I want to have information about the programs that are running, a little bit of extended information even. And I want to see numerical representations of host names and ports. I don't want to see domain name: HTTP. I want to see IP address:80 right? That's what I want to see.
Maxim Burgerhout (28:15):
So it's netstat -tulpen. Tulpen is Dutch for tulips. There we go. We're going to run this. This is going to give me a nice little list of all the processes that are running on this system, including httpd here on port 8001 and some other... sshd is running on port 22 as expected, that's the SSH port.
Maxim Burgerhout (28:33):
I can also do it without sudo, if you don't want to do this without... If you want to do this without sudo, that's fine as well, but you're going to miss out on the PID and programming information, which is very, very useful if you're doing a little bit of debugging. So there we go. That is what you do with netstat, figuring out what processes are running on your system. There's one, okay, let's do one more.
Maxim Burgerhout (28:55):
I showed you a little bit of SELinux, SELinux. But I'm still maybe a little complex. I only was able to show you a tiny aspect of that. If you want to learn more about SELinux you can use the man command, right? You can can use man SELinux and it'll give you a manual page. This manual page, as you might see, is not really that long. It's only 69 lines long and see that, you're on the bottom of the screen. What if I want to know more about SELinux? Where can I find more information on this running system about SELinux?
Maxim Burgerhout (29:21):
Well, there's this command called apropos, which is basically a search engine for your manual pages. I can run apropos selinux and it will give me a ton. It gives us close to 80 manual pages and information sources about SELinux you can all read and if you've read all this, you're about as much an SELinux guru as you can get. So that's what the apropos command does. It works for a lot of things. It's not just commands on Linux, but also kernel constructs and all the other very complex aspects of the system.
Maxim Burgerhout (29:51):
But if you want to know more about a topic, just don't go man vi, try apropos. Try apropos, apropos can give you a lot of more information than just a single man page. It just gives you all of the man pages.
Maxim Burgerhout (30:03):
I think I'm almost out of time. I'm just going to flip back through my presentation real quick. There we go. This one, we have seen. If you want to know a little bit more, Burr already mentioned the cheat sheet. This is the one I wrote, so it's Advanced Linux Commands. I hope you can see my arrow. You can... Yeah, you can see my arrow. The SS Linux Commands Cheat Sheet's over there. This is one Burr wrote, pre-dates mine by a couple of years, I think. Both of these two are really, really useful if you want to know a little bit more about Linux.
Maxim Burgerhout (30:35):
I mean, if you want to know a little bit more about SELinux, this is the guide for RHEL 8 that teaches you basically everything you need to know to deploy an application with SELinux enabled on a RHEL 8 machine and please do not turn off SELinux. SELinux is awesome and it helps you remain secure. If you're now saying, "But I don't have a subscription to RHEL 8."
Maxim Burgerhout (30:53):
Yes, you do. You can just go to developers.redhat.com/products/rhel/download. You can log in there, you can download RHEL 8 for free. You might need to create an account, but that's about it. You get a free developer subscription for RHEL 8. If you want to see more, DevNation Live talks, you go to developers.redhat.com/events. And finally, if you haven't registered for Summit yet, go to redhat.com/en/summit and register with Developer 20 because Red Hat Summit is really the coolest event of the year. I think I'm through, I'm not sure if I can pass control back to the team.
Speaker 3 (31:30):
well, we do have some questions for you.
Maxim Burgerhout (31:32):
Cool.
Speaker 3 (31:32):
We do have some questions for you. One right out of the gate is, does this only works in bash shell or can it work for other shells that might be part of part of the operating system?
Maxim Burgerhout (31:39):
Yeah, so there are a couple of shells that are delivered with RHEL 8. Bash is probably the most popular one because it's the default. We also ship at least the Zed shell or Z shell. I'm not sure how to pronounce it in this case or probably Korn shell still as well, K shell. This will work on Bash and most of it will work on Zed shell as well. History manipulation might be a little different on other shells than Bash, but all the other stuff will just work.
Burr Sutter (32:09):
Yep. Yep. Good point. And I think that's a very fair question. People like the cat EOS thing. I personally love that one as an example. Lots of comments on the different tips you showed. They were totally awesome. Tuxkey was actually was helping answer questions in the chat. Thank you so much that Tuxkey, and he had another question about that. The add-on you mentioned, do you have any more resources on that one? Any more data links?
Maxim Burgerhout (32:31):
I can get you some links, but I don't have them in hand right now, but I will... Let me update this deck and we can put the deck live somewhere, the slides download. I will have an extra link in there with information about manipulation systemd unit files, does that work?
Burr Sutter (32:45):
Okay. And is that on Twitter as well and that way people can-
Maxim Burgerhout (32:47):
Oh yeah, absolutely.
Burr Sutter (32:48):
-find it either way.
Maxim Burgerhout (32:49):
I can do it on Twitter. Yes, I will do it on Twitter. Good point.
Burr Sutter (32:54):
Okay. And unfortunately we are at of time, so hopefully you guys got some good tips and tricks for this session. I think it was totally fun. I picked up certain things and I'm not a day-to-day Linux tip admin. I'm more of a programming person, but Max, I love it.
Maxim Burgerhout (33:05):
Thank you.
Burr Sutter (33:06):
Thank you so much for doing this for us. We're going to have you on again.
Maxim Burgerhout (33:08):
You're welcome.
Burr Sutter (33:08):
You're on the show again where we have some more cool content to talk about. The Linux topics are always super popular here, so thank you guys so much for your time today. Do check out our YouTube channel, subscribe to that, follow that, and you'll get the information as these things get published. So more things will be coming out and if you have questions, feel free to reach out to Max or myself on Twitter and chase us down. You could always email me at burr@redhat.com as well. B-U-R-R@redhat.com, that'll find me. But thank you guys so much. Thank you. Back to Savannah now.
