When using Docker, or when using Docker as a container run-time for Kubernetes, over time, some unused data may build up on the system that runs Docker, for example on worker nodes of a Kubernetes cluster. This unused data may include images that were once downloaded locally, but are no longer used, for example, when a deployment to Kubernetes was once done, but later removed. This unused data may become quite a lot of data, and file systems may over time fill up because of this.
There is a simple Docker command that will prune all the unused data, and this command is:
# docker system prune -a
If you don't want to worry about pruning any unused Docker data, then schedule a cron job on your system as user root, like this:
0 */12 * * * * docker system prune -a -f
You can tunnel through an HTTP proxy using curl, using the -p command line option. This can be very usueful, if your organization uses a proxy to connect to the Internet.
What you'll need to know first it the full host name / URL of the proxy, as well as the port that it is available on, for example:
proxy.example.com:80
Next, run curl using the following options to access a site on the Internet. The example below assumes that the proxy is proxy.example.com:80 - please replace with the actual hostname and port combination of your proxy. Also, the command below gets the main page of Google - please replace it with the URL you are trying to connect to.
# curl -p -x http://proxy.examle.com:80 https://www.google.com
To display the number of CPUs available on the system, use the folowing command:
# nproc
You can also use the following command:
# grep processor /proc/cpuinfo | wc -l
Sometimes, e.g. after network related changes, it may be necessary to reset the iDRAC. If the iDRAC is no longer available, or if it is not responding, then it would be very difficult to reset the iDRAC at this point.
As an alternative, one can reset the iDRAC from the OS using the following command:
# racadm racreset
TMUX is short for Terminal Multiplexer. It is a way to run commands on multiple windows at the same time, or to split the terminal window in multiple panes.
Espcially, if you need to configure multiple nodes the same way, and thus have to run the same commands on different hosts, this tool might come in handy.
First, ensure it is installed.
# yum -y install tmux
Next, just start it, by running:
# tmux
This, in itself will not do much, except for displaying a bar at the bottom of the screen.
The key combination "CTRL + b" is the default prefix in TMUX. If you want to type any command to TMUX, then type "CTRL + b" first, and then use any of the following commands:
| " | split pane horizontally |
| % | split pane vertically |
| arrow key | switch between panes |
| c | create a new window |
| n | move to the next window (which you can divide into panes again) |
| p | move to the previous window |
To exit a window, simply type exit, or hit "CTRL + d".
To enable synchronization, e.g. after logging into 3 nodes in 3 panes within a window, run:
CTRL+b
:
set synchronize-panes on
To undo this, go through it again:
CTRL+b
:
set synchronize-panes off
If you run this command on Linux:
# cat /proc/sys/kernel/random/entropy_avail
it returns a number that indicates how much "entropy" is available to the kernel. But what exactly is "entropy", and what unit is this entropy measured in? What is it used for? You may have heard that a low number of entropy is not good. How low is "low" and what "bad" things will happen if it is? What's a good range for it to be at? How is it determined?
Entropy is similar to "randomness". A Linux system gathers "real" random numbers by keeping an eye on different events: network activity, hard drive rotation speeds, hardware random number generator (if available), key-clicks, and so on. If feeds those to the kernel entropy pool, which is used by /dev/random. Applications which use crypto functions, use /dev/random as their entropy source, or in other words, the randomness source.
If /dev/random runs out of available entropy, it's unable to serve out more randomness and the application waiting for the randomness may stall until more random bits are available. On Red Hat Enterprise Linux systems, you can see that RPM package rng-tools is installed, and that a rngd - random nubmer generator deamon - is active. This deamon feeds semi-random numbers from /dev/urandom to /dev/random in case /dev/random runs out of "real" entropy. On Ubuntu based systems, there is no rngd. If more entropy is needed you can install
haveged, which can achieve the same. Note that haveged is not available for Red Hat Enterprise Linux based systems, because these systems already have rngd.
Some applications (such as applications using encryption) need random numbers. You can generate random numbers using an algorithm - but although these seem random in one sense they are totally predictable in another. For instance if I give you the digits 58209749445923078164062862089986280348253421170679, they look pretty random. But if you realize they are actually digits of PI, then you may know the next one is going to be 8.
For some applications this is okay, but for other applications (especially security related ones) people want genuine unpredictable randomness - which can't be generated by an algorithm (i.e. program), since that is by definition predictable. This is a problem in that your computer essentially is a program, so how can it possibly get genuine random numbers? The answer is by measuring genuinely random events from the outside world - for example gaps between your key strokes and using these to inject genuine randomness into the otherwise predictable random number generator. The "entropy pool" could be thought of as the store of this randomness which gets built up by the keystrokes (or whatever is being used) and drained by the generation of random numbers.
The value stored in /proc/sys/kernel/random/entropy_avail is the measure of bits currently available to be read from /dev/random. It takes time for the computer to read entropy from its environment. If you have 4096 bits of entropy available and you "cat /dev/random" you can expect to be able to read 512 bytes of entropy (4096 bits) before the file blocks while it waits for more entropy. For example, if you "cat /dev/random" your entropy will shrink to zero. At first you'll get 512 bytes of random garbage, but it will stop and little by little you'll see more random data trickle trough.
This is not how people should operate /dev/random though. Normally developers will read a small amount of data, like 128 bits, and use that to seed some kind of PRNG algorithm. It's polite to not read any more entropy from /dev/random than you need to, since it takes so long to build up entropy, and it is considered valuable. Thus if you drain it by carelessly catting the file like above, you'll cause other applications that need to read from /dev/random to block.
A good number of available entropy is usually between 2500 and 4096 bits. Entropy is considered to be low when it is below 1000.
If you wish to send a file from a Linux or UNIX system, you can cat the file and pipe it into an email. For example, if you wish to send the contents of the /etc/hosts file in an email:
# cat /etc/hosts | mailx -s "subject goes here" your@email-address.com
This may not always be what you want, though. Sometimes, the file may be too large, or you may rather attach the file to an email.
To attach a file to an email, run it like this using -a option:
# echo "your message goes here" | \
mailx -s "your subject goes here" -a /etc/hosts your@email-address.com
Most email applications, like Microsoft Outlook, will put you text ("your message goes here") into the body of the email, and will attach /etc/hosts as a hosts.txt file for easy reading.
To attach larger files to an email (or for mail applications that handle zip files better as attachments), zip the file first before attaching it to an email message:
# zip /tmp/myzipfile.zip /etc/hosts
# echo "your message goes here" | \
mailx -s "your subject goes here" -a /tmp/myzipfile.zip your@email-address.com
If you wish to determine how much memory is installed in a Linux system, or perhaps the maximum amount of memory configurable on a system and the exact number and size of the memory DIMMs installed in the system, then you should use the dmidecode command.
The dmidecode command has a type option ( -t ), that can be used to indicate the type of device you wish to see detailed information for, like bios, system, baseboard, chassis, processor, cache, connector, slot and ... memory.
To retrieve the memory information, run the following command:
# dmidecode -t memory
You should get an output similar like the one below, but it can obviously differ per Linux system, depending on the hardware (model) and the installed memory.
# dmidecode -t memory
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
Handle 0x0047, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 16 GB
Error Information Handle: Not Provided
Number Of Devices: 2
Handle 0x0048, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0047
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 4096 MB
Form Factor: SODIMM
Set: None
Locator: DIMM A
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous
Speed: 1600 MT/s
Manufacturer: Hynix/Hyundai
Serial Number: 3248A01B
Asset Tag: 9876543210
Part Number: HMT351S6CFR8C-PB
Rank: 2
Configured Memory Speed: 1600 MT/s
Handle 0x004A, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0047
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 4096 MB
Form Factor: SODIMM
Set: None
Locator: DIMM B
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous
Speed: 1600 MT/s
Manufacturer: Kingston
Serial Number: BA33020F
Asset Tag: 9876543210
Part Number: KFYHV1-HYC
Rank: 2
Configured Memory Speed: 1600 MT/s
In the output above you can see that this particular system has a "Maximum Capacity" of 16 GB, and up to two "Number of Devices" can be installed.
Below it, you see the currently installed Memory Devices, the first one with a size of 4096 MB in slot DIMM A, with the exact Manufacturer and the Part Number listed. In slot DIMM B, you can also see another DIMM of 4096 MB installed, which is of a different vendor.
This information tells you, that the system shown above can be configured up to 16 GB of memory, but currently has two 4 GB memory DIMMs, thus 8 GB installed. In this case, upgrading the system to 16 GB of memory would mean replacing the two 4 GB memory DIMMs with two 8 GB memory DIMMs.
If you need to use a proxy for wget, this can be configured as follows:
Either create a file $HOME/.wgetrc (for a specific user) or /etc/wgetrc (to set the proxy configuration for the entire system), and add in the following lines, while replacing the entries below with your HTTP proxy URL and port information:
# You can set the default proxies for Wget to use for http and https.
# They will override the value in the environment.
https_proxy = http://proxy.yoyodyne.com:3128
http_proxy = http://proxy.yoyodyne.com:3128
# If you do not want to use proxy at all, set this to off.
use_proxy = on
Alternatively, you may also use the -e option for wget:
# wget ... -e https_proxy=http://proxy.yoyodyne.com:3128 ...
XRDP is an Open Source Remote Desktop Protocol server, very similar to what is used on Windows Server systems, but XRDP is meant for Linux. Once installed on Linux, you can set up a RDP (or Remote Desktop Connection) session from a Windows system directly to a Linux system.
Here's how you install and configure it on RHEL or CentOS 7:
First of all, we need to install the EPEL repository and XRDP server:
# yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
# yum -y install xrdp
Next, we need to start and enable the service:
# systemctl start xrdp.service
# systemctl enable xrdp.service
To check if its running, run:
# netstat -an | grep 3389
tcp 0 0 0.0.0.0:3389 0.0.0.0:* LISTEN
That's all. Now you can connect to your server from any Windows machine using RDP.
Number of results found for topic
System Admin: 249.
Displaying results: 1 - 10.
