You may remember that I have a small automation server in my home office that’s running Ubiquiti UniFi Controller software and where I upgraded UniFi Controller on Ubuntu 19.04.

I noticed that this server hasn’t been terribly available since upgrade to Ubuntu 19.04: more than once I went looking for the server and it was offline.

Now that I’m finally progressing with centralized RSyslog setup at home, I noticed that the UniFi controller server was reporting the following in logs recently:

So, it appears the power management has improved enough to start bringing this server to sleep every hour or so.

Since this is a recent enough version of Ubuntu, I figured there should be a way to disable power management using systemctl. Turns out, there is.

Confirm Sleep Status with systemd

IMPORTANT: I didn’t run this command on server, so this is example from another system: I’m running it on my XPS laptop with Ubuntu, just to show you expected output.

As you can see, my laptop rests well and often:

greys@xps:~ $ systemctl status sleep.target
 ● sleep.target - Sleep
    Loaded: loaded (/lib/systemd/system/sleep.target; static; vendor preset: enabled)
    Active: inactive (dead)
      Docs: man:systemd.special(7)
 Feb 24 13:18:08 xps systemd[1]: Reached target Sleep.
 Feb 26 13:29:31 xps systemd[1]: Stopped target Sleep.
 Feb 26 13:29:57 xps systemd[1]: Reached target Sleep.
 Feb 26 13:30:19 xps systemd[1]: Stopped target Sleep.

Disable Sleep in Ubuntu with systemd

This is what I did on my server:

root@server:/ # sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
 Created symlink /etc/systemd/system/sleep.target → /dev/null.
 Created symlink /etc/systemd/system/suspend.target → /dev/null.
 Created symlink /etc/systemd/system/hibernate.target → /dev/null.
 Created symlink /etc/systemd/system/hybrid-sleep.target → /dev/null.
 root@server:/etc/pm/sleep.d#

This is obviously a very simple way of disabling power management, but I like it because it’s standard and logical enough – there’s no need to edit config files or create cronjobs manually controlling sleep functionality.

The service is dead, no power management is happening and most importantly, my server has been up for 12 hours now.

greys@server:~$ systemctl status sleep.target
● sleep.target
   Loaded: masked (Reason: Unit sleep.target is masked.)
   Active: inactive (dead)

(re) Enabling Sleep in Ubuntu with systemctl

When the time comes and I would like to re-enable power management and sleep/hibernation, this will be the command I’ll run:

root@server:/etc/pm/sleep.d# sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target

That’s all for now. Have a great day!

See Also

• Ubuntu 19.10
• Dell XPS with Ubuntu Linux
• Ubiquiti Unifi Controller on Ubuntu 18.x
• Upgrading Unifi on Ubuntu 19.04
• Syslog logs with colours

If you’re on an unstable WiFi hotspot or simply forgot about a curl download and shut down your laptop, there’s a really cool thing to try: resume download from where you left off.

How To Download a File with curl

I’m downloading the Solus 4.1 release – it’s a 1.7GB ISO image. Here’s the command line that makes curl download the file and put it into local file (note the -O option):

greys@xps:~/Downloads/try $ curl -O http://solus.veatnet.de/iso/images/4.1/Solus-4.1-Budgie.iso  

How To Stop Download with curl

Now, if we press Ctlr+C to stop download, we’ll end up with a partially downloaded file:

greys@xps:~/Downloads $ curl -O http://solus.veatnet.de/iso/images/4.1/Solus-4.1-Budgie.iso
   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                         
                                  Dload  Upload   Total   Spent    Left  Speed                                           
   3 1692M    3 58.8M    0     0  2161k      0  0:13:21  0:00:27  0:12:54 4638k^C  

greys@xps:~/Downloads $ ls -la Solus*iso
-rw-r--r-- 1 greys  102318080 Feb  7 22:58 Solus-4.1-Budgie.iso
greys@xps:~/Downloads $ du -sh Solus-4.1-Budgie.iso
98M     Solus-4.1-Budgie.iso                               

How To Resume Download with curl

To resume download (rather than restart and begin downloading the whole file again0, simply use the -C option. It’s meant to be taking a specific offset in bytes, but also works if you specify “-“, when curl looks at existing file and decides what the offset should be automatically:

That’s it, you can let the download complete now:

greys@xps:~/Downloads $ curl -C - -O http://solus.veatnet.de/iso/images/4.1/Solus-4.1-Budgie.iso                        

** Resuming transfer from byte position 102318080                                                                       

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                         

                                 Dload  Upload   Total   Spent    Left  Speed                                           

100 1595M  100 1595M    0     0  2868k      0  0:09:29  0:09:29 --:--:-- 1766k         

Here’s my resulting file:

-rw-r--r-- 1 greys 1774911488 Feb  7 23:08 Solus-4.1-Budgie.iso

Don’t Forget to Compare File Checksum!

Checking a checksum for newly downloaded ISO image is always a good practice, but it becomes a must when you’re resuming downloads: in addition to ensuring you got the same ISO image software distributors intended, you’re getting the assurance that your resumed download file is intact and fully operational.

I have downloaded Solus 4.1 SHA256 checksum from the same Solus Downloads page, and will use the sha256sum command to generate checksum for the ISO file. Obviously, both checksums must match:

greys@xps:~/Downloads $ cat Solus-4.1-Budgie.iso.sha256sum 
4bf00f2f50e7024a71058c50c24a5706f9c18f618c013b8a819db33482577d17  Solus-4.1-Budgie.iso
greys@xps:~/Downloads $ sha256sum Solus-4.1-Budgie.iso
4bf00f2f50e7024a71058c50c24a5706f9c18f618c013b8a819db33482577d17  Solus-4.1-Budgie.iso

That’s it for today! I can’t wait to try Solus 4.1, will posh about it shortly.

See Also

• curl
• How To Resume wget downloads
• wget
• wget vs curl
• Check TCP connectivity with curl
• Ignore SSL warnings in curl

I’ve come across XZ files more than once, most recently when downloading Kali Linux. It should be a fairly common knowledge now, but some operating systems still don’t support is – so I decided to research and to document it.

What is XZ file?

XZ is a modern lossless compression algorithm, it’s more efficient that gzip and bzip2. Apparently, many Linux distros are using XZ for compressing their software packages or ISO images. XZ is an open-source format maintained via Tukaani Project – XZ.

Support for XZ in tar

Modern Linux distros (certainly Ubuntu 19.x and CentOS 7.x when I checked today) have xz utils package installed, which allows tar command to automatically unpack XZ files.

If xz-utils didn’t come preinstalled, you can install it like this in Ubuntu/Debian:

# apt install xz-utils

or like this in CentOS/Fedora/RedHat:

# yum install xz

gzip/gunzip Support for XZ in macOS

Although tar in macOS doesn’t support XZ format natively:

greys@mcfly:~/Downloads $ tar xzvf kali-linux-2020.1-rpi3-nexmon-64.img.xz
 tar: Error opening archive: Unrecognized archive format

… you can still use gunzip to decompress the XZ file in macOS:

greys@mcfly:~/Downloads $ ls -al kali-linux-2020*
-rw-r--r--@ 1 greys  staff      259647 30 Jan 22:57 kali-linux-2020-1.png
-rw-r--r--@ 1 greys  staff  1048328860 30 Jan 23:06 kali-linux-2020.1-rpi3-nexmon-64.img.xz
greys@mcfly:~/Downloads $ gunzip kali-linux-2020.1-rpi3-nexmon-64.img.xz
greys@mcfly:~/Downloads $ ls -ald kali-linux-2020.1-rpi3-nexmon-64.img
-rw-r--r--  1 greys  staff  6999999488 30 Jan 23:06 kali-linux-2020.1-rpi3-nexmon-64.img

xz-utils in macOS

If you insist on managing XZ files using xz utils, you’ll need to install them with brew:

… and then a whole bunch of XZ commands becomes available:

xz
xzcat
xzcmp
xzdec
xzdiff
xzegrep
xzfgrep
xzgrep
xzless
xzmore

See Also

• XZ utils website
• 7zip in Ubuntu
• How To Use 7zip

I have a number of servers, including a few on the home office network, that accept SSH connections. Even though they are serving on different (non-standard) SSH ports, there are regular attempts made to break it via brute-force – I can see how some random IP addresses start trying to log in using different standard user names. It’s therefore never too late to use additional software for protecting SSH service, something like fail2ban.

What is fail2ban?

fail2ban is a tool that monitors OS logs, identifies failed connection and authentication (login) attempts and then temporarily bans these IP addresses using IPtables.

The idea is that any IP address that failed to login multiple times within a period of time must be blocked from further attempts to log in on a firewall level. This minimises risks because connections are simply blocked rather than allowed to try another username/password combination.

INTERESTING: fail2ban can do a lot more than just protect your SSH service – it has a growing library of contextual log files knowledge.

Install fail2ban in Ubuntu

Even on my Raspberry system I can just do this to install fail2ban:

$ sudo apt install fail2ban

IMPORTANT: double-check that you have iptables installed – think it would be installed as part of dependencies for fail2ban.

Once installed, this software needs to be activated – so you need to start it using systemctl or service command.

Configure fail2ban

Before we can start, it makes sense to customise fail2ban to make sure it’s going to work properly.

Basic settings I focus on are:

• SSH port – by default fail2ban will keep blocking standard SSH port 22, which isn’t going to be all that helpful if your SSH service is listening on a different TCP port
• Configure email – fail2ban will notify you of new bans/unbans

So just edit the /etc/fail2ban/jail.conf file as root. I made the following changes:

How to Use fail2ban

Start the service:

$ sudo systemctl start fail2ban

and check its log file:

2020-01-09 22:32:55,710 fail2ban.server         [6038]: INFO    --------------------------------------------------  
2020-01-09 22:32:55,712 fail2ban.server         [6038]: INFO    Starting Fail2ban v0.10.2  
2020-01-09 22:32:55,727 fail2ban.database       [6038]: INFO    Connected to fail2ban persistent database '/var/lib/fail2ban/fail2ban.sqlite3'  
2020-01-09 22:32:55,731 fail2ban.jail           [6038]: INFO    Creating new jail 'sshd'  
2020-01-09 22:32:55,779 fail2ban.jail           [6038]: INFO    Jail 'sshd' uses pyinotify {}  
2020-01-09 22:32:55,798 fail2ban.jail           [6038]: INFO    Initiated 'pyinotify' backend  
2020-01-09 22:32:55,801 fail2ban.filter         [6038]: INFO      maxLines: 1  
2020-01-09 22:32:55,934 fail2ban.server         [6038]: INFO    Jail sshd is not a JournalFilter instance  
2020-01-09 22:32:55,936 fail2ban.filter         [6038]: INFO    Added logfile: '/var/log/auth.log' (pos = 385669, hash = 9d2089e21756515d4394ead79bad08c298835101)  
2020-01-09 22:32:55,939 fail2ban.filter         [6038]: INFO      encoding: UTF-8  
2020-01-09 22:32:55,940 fail2ban.filter         [6038]: INFO      maxRetry: 3  
2020-01-09 22:32:55,942 fail2ban.filter         [6038]: INFO      findtime: 600  
2020-01-09 22:32:55,943 fail2ban.actions        [6038]: INFO      banTime: 1800  
2020-01-09 22:32:55,974 fail2ban.jail           [6038]: INFO    Jail 'sshd' started  
2020-01-10 02:46:49,790 fail2ban.filter         [6038]: INFO    [sshd] Found 218.93.239.44 - 2020-01-10 02:46:49  
2020-01-10 02:46:49,825 fail2ban.filter         [6038]: INFO    [sshd] Found 218.93.239.44 - 2020-01-10 02:46:49  
2020-01-10 02:46:51,811 fail2ban.filter         [6038]: INFO    [sshd] Found 218.93.239.44 - 2020-01-10 02:46:51  
2020-01-10 02:46:52,382 fail2ban.actions        [6038]: NOTICE  [sshd] Ban 218.93.239.44

How To Inspect fail2ban Logs

As you can see from the output, the service created a “jail” for SSHd service and started looking at failed SSH login attempts. I started fail2ban at 22:32 last night, and at 2:46am got the first IP address blocked: it found 3 failed logins from 218.93.239.44 and banned it immediately.

You can also check iptables, they might have some IP addresses blocked already:

root@srv:/# iptables -nvL
 Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source               destination
   266 17432 f2b-sshd   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 202
 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source               destination
 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source               destination
 Chain f2b-sshd (1 references)
  pkts bytes target     prot opt in     out     source               destination
     0     0 REJECT     all  --  *      *       218.93.239.44        0.0.0.0/0            reject-with icmp-port-unreachable
   266 17432 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

That’s it for one day. Hope you’ve learned something new today!

See Also

• SSH reference
• SSH port
• Testing different config for SSH
• SSH port forwarding

This is a fairly straightforward procedure, I just want to capture it here for my own future use.

Install Ruby Version 2.4.0 or Better

Your macOS comes with Ruby pre-installed, but unfortunately it’s not recent enough to support Jekyll 4.

In macOS Mojave I have the following ruby version:

greys@mcfly:~ $ ruby -v
ruby 2.3.7p456 (2018-03-28 revision 63024) [universal.x86_64-darwin18]

Now that Jekyll 4 is the default, you simply install jekyll gem and it will get you the latest version of the 4.x branch.

But Jekyll gem install would fail with one of the dependencies like this:

greys@mcfly:~/proj/gleb.reys.net $ sudo gem install jekyll
Password:
Fetching: public_suffix-4.0.1.gem (100%)
Successfully installed public_suffix-4.0.1
Fetching: addressable-2.7.0.gem (100%)
Successfully installed addressable-2.7.0
Fetching: colorator-1.1.0.gem (100%)
Successfully installed colorator-1.1.0
Fetching: http_parser.rb-0.6.0.gem (100%)
Building native extensions.  This could take a while…
Successfully installed http_parser.rb-0.6.0
Fetching: eventmachine-1.2.7.gem (100%)
Building native extensions.  This could take a while…
Successfully installed eventmachine-1.2.7
Fetching: em-websocket-0.5.1.gem (100%)
Successfully installed em-websocket-0.5.1
Fetching: concurrent-ruby-1.1.5.gem (100%)
Successfully installed concurrent-ruby-1.1.5
Fetching: i18n-1.7.0.gem (100%)
HEADS UP! i18n 1.1 changed fallbacks to exclude default locale.
But that may break your application.
Please check your Rails app for 'config.i18n.fallbacks = true'. If you're using I18n (>= 1.1.0) and Rails (< 5.2.2), this should be
'config.i18n.fallbacks = [I18n.default_locale]'.
If not, fallbacks will be broken in your app by I18n 1.1.x.
For more info see:
https://github.com/svenfuchs/i18n/releases/tag/v1.1.0
Successfully installed i18n-1.7.0
Fetching: ffi-1.11.1.gem (100%)
Building native extensions.  This could take a while…
Successfully installed ffi-1.11.1
Fetching: sassc-2.2.1.gem (100%)
Building native extensions.  This could take a while…
Successfully installed sassc-2.2.1
Fetching: jekyll-sass-converter-2.0.1.gem (100%)
ERROR:  Error installing jekyll:
    jekyll-sass-converter requires Ruby version >= 2.4.0.

Which means that we need to upgrade Ruby, easily done with brew.

Simply install latest Ruby with Homebrew:

greys@mcfly:~/proj/gleb.reys.net $ brew install ruby
...
greys@mcfly:~/proj/gleb.reys.net $ ruby -v
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin18]

Install Jekyll 4 gem

Now let’s try installing Jekyll 4 again:

greys@mcfly:~/proj/gleb.reys.net $ sudo gem install jekyll
 Password:
 Jekyll 4.0 comes with some major changes, notably:
 Our link tag now comes with the relative_url filter incorporated into it.
 You should no longer prepend {{ site.baseurl }} to {% link foo.md %}
 For further details: https://github.com/jekyll/jekyll/pull/6727
 Our post_url tag now comes with the relative_url filter incorporated into it.
 You shouldn't prepend {{ site.baseurl }} to {% post_url 2019-03-27-hello %}
 For further details: https://github.com/jekyll/jekyll/pull/7589
 Support for deprecated configuration options has been removed. We will no longer
 output a warning and gracefully assign their values to the newer counterparts 
     internally.
 Successfully installed jekyll-4.0.0
 Parsing documentation for jekyll-4.0.0
 Done installing documentation for jekyll after 0 seconds
 1 gem installed

That’s it – Jekyll is ready for developing static websites!

See Also

• Jekyll
• Jekyll 4.0.0
• Jekyll website on Netlify
• Unix Tutorial Project: Jekyll website with GitHub Pages
• macOS

One of the least used and usually forgotten features in Linux/Unix filesystems, sticky bit is a great way to manage regular user access to a shared directory.

What is a sticky bit?

Sticky bit is a special flag that changes how a particular directory in Unix works. Without this flag, any user that has enough file permissions can remove or rename somebody else’s file in a directory. With sticky bit set, only the original owner of a file can remove or rename it – other users will get permission denied.

IMPORTANT: there’s also an even less popular scenario of using sticky bit for files – but I’ll explain it in a separate post.

How sticky bit for a directory looks

Here’s a directory I just created as myself on my laptop:

greys@maverick:~ $ ls -lad /tmp/try
drwxr-xr-x  2 greys  wheel  64 17 Dec 08:33 /tmp/try

I plan on sharing this directory with another user, called unixtutorial. So I’m opening permissions wide (warning! do this only for shared directories that contain no sensitive data):

greys@maverick:~ $ chmod a+rwx /tmp/try
greys@maverick:~ $ ls -lad /tmp/try
drwxrwxrwx  2 greys  wheel  64 17 Dec 08:33 /tmp/try

Let’s set the sticky bit for this /tmp/try directory:

greys@maverick:~ $ chmod +t /tmp/try

Here’s how it will look (note how last rwx in permissions changed to rwt – t is the sticky bit):

greys@maverick:~ $ ls -lad /tmp/try
drwxrwxrwt  2 greys  wheel  64 17 Dec 08:33 /tmp/try

How sticky bit works

I’m creating a file in the sticky-bit protected directrory /tmp/try that any user on my OS can access for read and write:

greys@maverick:~ $ touch /tmp/try/file1
greys@maverick:~ $ ls -lad /tmp/try/file1
-rw-r--r--  1 greys  wheel  0 17 Dec 08:34 /tmp/try/file1
greys@maverick:~ $ chmod 666 /tmp/try/file1
greys@maverick:~ $ ls -lad /tmp/try/file1
-rw-rw-rw-  1 greys  wheel  0 17 Dec 08:34 /tmp/try/file1

… but if I start another terminal session as user unixtutorial, I can’t remove this file even though rw- permissions should allow it:

unixtutorial@maverick:~ $ sudo su - unixtutorial
Password:
unixtutorial@maverick:~ $ cd /tmp/try
unixtutorial@maverick:/tmp/try $ rm /tmp/try/file1
rm: /tmp/try/file1: Permission denied

unixtutorial@maverick:/tmp/try $ ls -la /tmp/try/file1
 -rw-rw-rw-   1 greys  wheel    0 Dec 17 08:34 file1

If as my original user greys I remove the sticky bit from /tmp/try:

greys@maverick:~ $ chmod -t /tmp/try
greys@maverick:~ $ ls -ald /tmp/try
drwxrwxrwx  2 greys  wheel  64 17 Dec 08:36 /tmp/try

… I can now remove the file as another user:

unixtutorial@maverick:/tmp/try $ rm /tmp/try/file1
unixtutorial@maverick:/tmp/try $ ls -al /tmp/try/file1
ls: /tmp/try/file1: No such file or directory

Sticky Bit Clarifications

1. You can’t apply sticky bit to a user or group, as you would with other file access permissions. It works on a file or directory level, not user or group level.

   This is invalid: chmod u+t

   This is correct: chmod +t

2. Sticky bit only controls regular users – super user root can still remove any files in sticky-bit protected directories, even owned by other users

That’s it for today. Hope you have learned something new!

See Also

• Basic Unix commands
• ls command
• chmod command
• Advanced Unix Commands

I’m finishing up the VM based Ubuntu 19.10 setup and decided to make a few screenshots to test new workflow. Instead of random topic, I documented the task of configuring Ubuntu to use static IP address.

Why use Static IP?

Desktops don’t benefit from this much, but servers benefit from having static (fixed) IP addresses because you configure DNS once and then use server hostname and same fixed IP address for using any services.

Even if all you need is connect to server via SSH, static IP address will make things much easier – plus it usually comes as default for most dedicated hosting plans.

In my home lab I prefer to configure most virtual machines with static IP addresses because this allows me to easily access them remotely (working from one of the laptops).

Things to Know Before Configuring Static IP

Assuming you’re going to assisg a static IP from your local network (LAN), you need to have the following information confirmed:

• what’s the local network addressing in use? It most likely starts with 192.168 or 10.0, but you need to know for sure. You need the full network – so something like 192.168.0.x or 192.168.1.x
• static IP address you plan to use (from the same network)
  • make sure this IP is available – currently not in use (and at least does not answer to ping)
• default route (sometimes called gateway) address – this is usually the IP address of your broadband modem. In my case it’s 192.168.1.1
• DNS server IP address – usually the same as your gateway IP
  • you can also easily use external DNS server like 1.1.1.1 (CloudFlare) or 8.8.8.8 (Google)

Configure Ubuntu 19.10 for Static IP

Here are the screenshots walking you through the static IP configuration:

Go to app listing:

… choose Settings:

and select Network:

Inspect current settings (they would be automatic IP address and DNS details via DHCP):

…and now go to IPv4 settings:

Now, select Manual option for IPv4 method:

…and provide new values:

Now click Apply (top right) and in the next screen turn the Wired network off:

Now turn it back on and you can review the result:

That’s it – it’s a rather simple procedure but I still find it more comfortable (and easier to manage) when I update configuration directly or via Ansible.

See Also

• Ubuntu 19.10
• ZFS on root in Ubuntu 19.10
• Ubuntu 19.04 on Dell XPS Laptop
• Ubuntu Linux

Back to basics day: a very simple tip on working with one of the most useful things available in Unix and Linux filesystems: symbolic links (symlinks).

How Symlinks Look in ls command

When using long-form ls output, symlinks will be shown like this:

greys@mcfly:~/proj/unixtutorial $ ls -la
total 435736
-rwxr-xr-x   1 greys  staff        819 14 Dec  2018 .gitignore
drwxr-xr-x   3 greys  staff         96 20 Nov 09:27 github
drwxr-xr-x   4 greys  staff        128 20 Nov 10:58 scripts
lrwxr-xr-x   1 greys  staff         30 10 Dec 20:40 try -> /Users/greys/proj/unixtutorial
drwxr-xr-x  44 greys  staff       1408 20 Nov 10:54 wpengine

Show Symlink Destination with readlink

As with pretty much everything in Unix, there’s a simple command (readlink) that reads a symbolic link and shows you the destination it’s pointing to. Very handy for scripting:

greys@mcfly:~/proj/unixtutorial $ readlink try
/Users/greys/proj/unixtutorial

It has a very basic syntax: you just specify a file or directory name, and if it’s a symlink you’ll get the full path to the destination as the result.

If readlink returns nothing, this means the object you’re inspecting isn’t a symlink at all. Based on the outputs above, if I check readlink for the regular scripts directory, I won’t get anything back:

greys@mcfly:~/proj/unixtutorial $ readlink scripts
greys@mcfly:~/proj/unixtutorial $

See Also

• Basic Unix Commands
• Advanced Unix Commands
• ln command
• Symlink example
• Unix Tutorial Glossary

macOS has a very flexible and striving kernel modules ecosystem. There are so many granularities for integrating with OS kernel that modules are called extensions. Many third party software packages install their own kernel extensions in macOS.

List Kernel Extensions in macOS

Here’s how many kernel extensions my MacBook with macOS Catalina runs:

greys@MacBook-Pro:~ $ kextstat
Index Refs Address            Size       Wired      Name (Version) UUID 
    1  141 0xffffff7f80c3e000 0xc340     0xc340     com.apple.kpi.bsd (19.0.0) 4138A7E1-7AAC-46CC-A40D-B3CD34D42A0F
    2   12 0xffffff7f8106f000 0x5d00     0x5d00     com.apple.kpi.dsep (19.0.0) 28FFE9F3-6AA9-4B45-8083-5E1F8339A1B7
    3  171 0xffffff7f80c07000 0x25750    0x25750    com.apple.kpi.iokit (19.0.0) F32F3E6F-CA35-474E-A19D-DA902B7DF058
    4    0 0xffffff7f84153000 0x57e0     0x57e0     com.apple.kpi.kasan (19.0.0) D8CD3720-E2FA-4653-9782-75A7A305A795
    5  177 0xffffff7f80c2d000 0x10070    0x10070    com.apple.kpi.libkern (19.0.0) EF0ABB46-BDD6-43F7-BA12-94619B2FC0D8
    6  158 0xffffff7f80c00000 0x62e0     0x62e0     com.apple.kpi.mach (19.0.0) AE30D5D8-CC3C-491C-804D-297CD2CDE62A
    7   88 0xffffff7f80c54000 0x104c0    0x104c0    com.apple.kpi.private (19.0.0) 1F6F48E4-F657-406A-B278-F6D4E2175FD3
    8  100 0xffffff7f80c4b000 0x8200     0x8200     com.apple.kpi.unsupported (19.0.0) 5C7AA78C-E5AD-4D6A-97F5-42F9B3766819
    9    2 0xffffff7f80db9000 0x10000    0x10000    com.apple.kec.Libm (1) 9946AE67-6E42-30DF-8E4D-BA58C59B961E <5>
   10   11 0xffffff7f81699000 0xd8000    0xd8000    com.apple.kec.corecrypto (1.0) 827A0D77-211B-330E-8C84-A0DE01F13426 <8 7 6 5 3 1>

...

  233    1 0xffffff7f85713000 0x6000     0x6000     com.apple.driver.usb.serial (6.0.0) 57547DE4-80AD-3418-B964-2D6370E3C92A <102 28 6 5 3 1>
  234    0 0xffffff7f85719000 0x8000     0x8000     com.apple.driver.usb.cdc.acm (5.0.0) A5C845ED-E909-3B4A-8C20-F4013C9AA466 <233 107 106 105 102 28 6 5 3 1>

greys@MacBook-Pro:~ $ kextstat  | wc -l
     186

Show Third Party Kernel Extensions

It is so common for software to be installing kernel extensions in macOS, that some extensions stay running long after you stop using the software that brought them. Whether extensions stay or not highly depends on how you removed or upgraded the software (most installers are pretty good at tidying up).

If you exclude extensions starting with com.apple, you can see the third party ones:

greys@MacBook-Pro:~ $ kextstat  | grep -v com.apple
Index Refs Address            Size       Wired      Name (Version) UUID 
   17    0 0xffffff7f81075000 0xc000     0xc000     com.fsecure.XFENCE (1.8.88) 83DEF05D-E416-322C-871A-55308708CB27 <8 6 5 3 2 1>
   95    0 0xffffff7f810b0000 0x185000   0x185000   at.obdev.nke.LittleSnitch (5430) 7462BC7A-1330-3F92-A73F-3FBFE331C74A <8 6 5 3 1>
  139    0 0xffffff7f813b1000 0x6000     0x6000     com.acronis.fileprotector (1.5) F74F91DC-0D15-3880-B60A-81070629A1D5 <29 8 6 5 3 1>
  166    0 0xffffff7f8148f000 0x6000     0x6000     com.valvesoftware.SteamInput (3083.39.62) DED4413E-CD8E-3E56-B0AB-7B3B20ECE4BF <50 6 5 3>
  167    0 0xffffff7f8145e000 0x1e000    0x1e000    com.kaspersky.kext.klif (3.6.15a14) 86F2DE0E-8DBE-3DEA-B091-7E459F9739B9 <29 6 5 3 1>
  168    0 0xffffff7f8144c000 0xc000     0xc000     com.kairos.driver.DuetDisplay (1) 7620686C-E9CE-3C70-AA12-DC77DABA52DD <117 6 5 3>
  170    0 0xffffff7f812fb000 0x7000     0x7000     org.pqrs.driver.Karabiner.VirtualHIDDevice.v040600 (4.6.0) D92AF3AB-DDF6-3B68-B481-7297ABD9F291 <50 6 5 3 1>
  171    0 0xffffff7f80ff6000 0x5c000    0x5c000    com.kaspersky.nke (2.4.7a10) 5BA7A711-DA4B-3557-83EE-FABA43B43968 <19 8 6 5 3 1>
  172    0 0xffffff7f80ebc000 0x7000     0x7000     com.AmbrosiaSW.AudioSupport (4.1.4) no UUID <115 6 5 3 1>
  173    0 0xffffff7f80dac000 0x5000     0x5000     com.techsmith.TACC (1.0.3) 851BEDD1-1D12-3756-A948-978610078DEF <6 5 3>
  188    0 0xffffff7f855b6000 0x5000     0x5000     org.pqrs.driver.Karabiner.VirtualHIDDevice.v061000 (6.10.0) 4D004D1A-ED2F-3780-AD53-A10F286EC759 <50 6 5 3 1>

greys@MacBook-Pro:~ $

This has been a useful exercise, cause I already see how some kexts are no longer needed – I’ll find out how to safely remove them and will create another post on Unix Tutorial later.

See Also

• macOS
• Automating macOS screenshots with Hazel
• macOS Catalina

Super quick advice today, but one of them pearls of experience that now and then saves your day. Learn how to check and confirm your recent changes to SSH daemon config file (/etc/ssh/sshd_config) won’t break your remote SSH access.

Why Double-Checking Configs Is A Good Idea

I should probably start a special section of Unix Tutorial someday, just to talk about how and when things can go wrong. These things below would certainly belong to that section.

Why it’s a good idea to check that your new config file is error free:

• avoid getting service outage (syntax error means service won’t restart)
• prevent service malfunction (if you end up with only partial service functionality)
• don’t get yourself locked out of service (or server, in case of broken SSH)

How To Check SSHd Config

I have shown you before how to test new SSHd config on a different port, but there’s also a way to check primary config.

Here’s how you do it:

greys@s2:~ $ sudo sshd -t 

It will either return nothing, or complain about errors or highlight deprecated options, like this:

greys@s2:~ $ sudo sshd -t
/etc/ssh/sshd_config line 56: Deprecated option RSAAuthentication

That’s all there is to it, enjoy!

See Also

• SSH reference
• Passwordless SSH
• SSHd on different port
• Basic SSH configuration
• SSH port
• SSH port forwarding
• Check SSH port status