I just realized that both are places that one might put software not “native” to a system. I found this post and here are the main points to get the gist: /usr/local is a place to install files built by the administrator, typically by using the make command. The idea is to avoid clashes with files that are part of the operating system… On the other hand, /opt is a directory for installing unbundled packages, each one in its own subdirectory.

I was recently asked how to show threads instead of PIDs using the ‘ps’ command. I wanted to find out why that’s even desired in the first place. I don’t have experience dealing with such things. I did learn new things, but still don’t really know why one would care about listing the threads. Can one manipulate them? Wouldn’t it cause erratic behavior? Is the killing of individual threads of a process allowed from outside?

Just a quick reference Regular file (-) Directory (d) Symlink (l) Named pipe (p) Socket (s) Character device (c) Block device (b)

Disable/enable on the fly Either turn it on: sudo setenforce enforcing or turn it off: sudo setenforce permissive These aren’t permanent changes; next reboot it’ll go back to whatever the config is set to. But this will let you on the fly turn on or off SELinux. I use it if I suspect SELinux to be blocking something. Change context Sometimes one has to change context of a file or directory.

/boot/grub2/grub.cfg has a list of menuentries with a lot of information in each. Starting at 0 count down to the one you want (you could script this out too). Then take that number and edit /etc/default/grub. In that file, add (or edit) a line: GRUB_DEFAULT=x x being the number of the menuentry you picked from looking in /boot/grub2/grub.cfg Then you have to update the grub.cfg file by running: grub2-mkconfig -o /boot/grub2/grub.

I wanted to write this down for my own reference. I’ve been dealing with dd a bit recently and the whole block size issue comes up. What is optimal? That depends on your hardware. This article here has a way to test and determine what the optimal block size is: http://blog.tdg5.com/tuning-dd-block-size/

FG BG jobs nohup, disown, screen Jobs What are Jobs? A job is a concept used by the shell – any program you interactively start that doesn’t detach (ie, not a daemon) is a **job. **Jobs can reside in the foreground (spitting output to the terminal) or in the background (they run, but you don’t get their output spat to the terminal). One can send a job to BG right away using the ‘&’ at the end of the command.

Just a quick note, I had to open up a hole in the firewall on the server itself (even though I had my router stuff all set right already) by doing: <i>sudo firewall-cmd --permanent --zone=public --add-port=80/tcp sudo firewall-cmd --reload </i> Worked great. I guess having a firewall on the server itself is good too. Instead of just relying on the one on the outer edge of the network.

So I bought a simple dual core desktop machine recently to use as a simple server. I fired it up with centos 7’s “minimal” ISO. Got up and going, network didn’t work (lights were flashing, but nothing but a loopback device was recognized by the system). So I installed the “DVD” iso, hoping it would have whatever extra thing in it that was needed for the networking but still no dice.

Redirecting stdin is a channel where one provides input (keyboard, typically) stdout is a channel that a script or program uses to output information stderr is another channel used by a script or program to output errors < redirect stdin redirect stdout 2> redirect stderr Examples: This redirects any errors to the ‘err’ file ls nonexistentfile 2&gt; err This redirects any actual output to the ‘out’ file and errors to ‘err’

The only thing I really need to know is that this command displays all of them from the current session: env<del></del> But I guess I’ll write down some other stuff too. The ‘export‘ command makes a variable available to any children of the current session. That’s the only real reason that it should be used. Otherwise you can prepend to the path for instance using: PATH=/home/myself/bin/:$PATH You can unset variables using the ‘unset‘ command

Just needed to know recently how many inodes one can expect on a basic VPS server. According to ArchWiki: mkfs.ext4 uses by default a rather low ratio of one inode every 16384 bytes (16 Kb) Which roughly boils down to 1M inodes per 15GB of space.