How to setup znapzend with local backup on OpenIndiana

This guide will show you how to set up znapzend on OpenIndiana to backup a ZFS fileystem to a different ZFS filesystem.

Assumptions

1. The backup destination ZFS zpool, e.g. destinationzpool, has already been created
2. The backup destination ZFS dataset, e.g. destinationzpool/destinationzfsdataset has already been created
3. Both of the above are on the same machine as the source dataset

See the Oracle Solaris docs for instructions on Steps 1 to 3. At that link, pick the latest Solaris release and search the ensuing page for “ZFS.”

Step 1: Set up the pkgsrc repo

As of this writing, znapzend does not exist in the OpenIndiana repos, so you’ll have to set up the 3rd party pkgsrc repo that has it.

Step 2: Install znapzend

# pkgin install znapzend

Step 3: Configure znapzend

The official documentation is overly complicated for this purpose. A simple example config is:

znapzendzetup create --recursive SRC '1h=>15min,1d=>1h,1w=>1d,1m=>1w,1y=>1m' sourcezpool DST '1h=>15min,1d=>1h,1w=>1d,1m=>1w,1y=>1m' destinationzpool/destinationzfsdataset

Explaining the above command:

• znapzendzetup: Set up znapzend
• create: Generate a new backup config
• --recursive: Backup all child datasets on sourcezpool
• SRC: Source zpool settings begin here
• '1h=>15min,1d=>1h,1w=>1d,1m=>1w,1y=>1m': For each comma-separated parameter, take a snapshot at interval equal to the value to the right of the arrow, and then destroy that snapshot after the value to the left of the arrow, e.g. 1h=>15min means take a snapshot every 15 minutes and destroy all such snapshots after they’ve existed for an hour. See official documentation for more options
• sourcezpool: The zpool you want to backup
• DST: Destination zpool & ZFS dataset settings begin here
• '1h=>15min,1d=>1h,1w=>1d,1m=>1w,1y=>1m': Same as before
• destinationzpool/destinationzfsdataset: The destination zpool and ZFS dataset

Step 4: Check your znapzend config

# znapzend --noaction --debug

The output of the above command may appear to freeze and not return you to a prompt. If that happens just hit CTRL + C until the prompt shows up again. As long as the output has no errors, your config should be good.

Step 5: Start znapzend in the background

# znapzend --daemonize

Step 6: Wait for the smallest interval set in Step 3

Step 7: Check that znapzend is creating snapshots as configured

# zfs list -t snapshot

You should see snapshots with %Y-%m-%d-%H%M%S (znapzend‘s default) timestamps in their names.

Step 8: Kill znapzend

There are many ways to do this, but I prefer using htop (install it from the OI repos if you haven’t already):

• # htop
• Press F4 to filter
• Type znapzend
• Use the arrow keys to highlight any matching entries
• Press F9 while each matching entry is highlighted to kill it
• Press F10 to exit

Step 9: (Optional) Disable other snapshot utilities

CoW filesystems like ZFS sometimes have difficulty with a large number of snapshots combined with low space. Also, destroying snapshots is computationally expensive, and taking them too frequently can slow down the machine.

Therefore, it’s a good idea to disable other snapshot utilities if they are likely to cause such issues. For example, if you use Time Slider:

• Open Time Slider
• Uncheck Enable Time Slider
• Click Delete Snapshots
• In the window that follows, click Select All
• Click Delete

The deletion process may take a very long time (I suggest running it overnight.) If any Time Slider snapshots remain after the bulk deletion, just run it again and that should take care of the rest.

Step 10: Generate a znapzend service manifest

Wouldn’t it be nice if you could start znapzend at boot? Unlike Linux and FreeBSD, OI’s crontab syntax lacks an @reboot option, so anything that starts with OS has to be a service. While @reboot makes things simple, service creation has some advantages, such as alerting the user when a service isn’t running as expected.

sudo svccfg export znapzend

Copy the output of that command to a text editor. You could also possibly use | or echo to combine this and the following manifest file creation steps.

BONUS: You can use svccfg export combined with the following steps to turn just about any background executable into a service!

Step 11: Create the znapzend service manifest XML file

Create the following file /var/svc/manifest/site/znapzend.xml using your preferred method, then copy the output of Step 10 to it and save the file.

I use:

# nano /var/svc/manifest/site/znapzend.xml

• Copy the output from Step 10 into nano
• Press CTRL + O to save the file
• Press CTRL + X to exit

Step 12: Validate the manifest file

# svccfg validate /var/svc/manifest/site/znapzend.xml

Step 13: Import the manifest file

# svccfg import /var/svc/manifest/site/znapzend.xml

Step 14: Start the znapzend service

# svcadm enable znapzend

And that’s it. Now you have automatic, incremental, rotating, easily restored backups of your OS filesystem.

from jdrch https://dev.to/jdrch/how-to-setup-znapzend-with-local-backup-on-openindiana-1f0p
via IFTTT

Which FreeBSD directories to backup for bare metal recovery

Like OpenIndiana, FreeBSD uses a ZFS root filesystem by default. Ergo, the backup method is approximately the same: backup everything that’s a ZFS filesystem and exclude the rest. Additional exclusions:

/dev/*
/tmp/*
/mnt/*
/proc/*
/compat/*

from jdrch https://dev.to/jdrch/which-freebsd-directories-to-backup-for-bare-metal-recovery-22c7
via IFTTT

Which Linux directories to backup for bare metal recovery

This post pertains mostly to Debian(10 and distributions based on it) and Raspberry Pi OS, but can most likely be extended to other distributions.

For Debian, backup everything except the following:

/proc/*
/sys/*
/dev/*
/run/*
/etc/mtab
/var/cache/apt/archives/*.deb
lost+found/*
/tmp/*
/var/tmp/*
/var/backups/*
.Private
/mnt/*

For Raspberry Pi OS, backup everything except the following:

/proc/*
/sys/*
/dev/*
/run/*
/etc/mtab
/var/cache/apt/archives/*.deb
lost+found/*
/tmp/*
/var/tmp/*
/var/backups/*
/mnt/*
/media/*
/svr/*

from jdrch https://dev.to/jdrch/which-linux-directories-to-backup-for-bare-metal-recovery-c3e
via IFTTT

How to set up email notifications on OpenIndiana

Do you want your OpenIndiana instance to let you know when something has gone wrong or if a cron job has failed? Here’s how you do it.

First, tell the operating system to email you if anything goes into the maintenance, offline, or degraded states:

# svccfg setnotify -g to-maintenance,to-offline,to-degraded mailto:YourEmailAddress

For failed cron jobs and the like, add the following lines to /etc/mail/aliases:

root:           YourEmailAddress
YourUsername:          YourEmailAddress

Ensure there are no other conflicting root & YourUsername definitions (read: lines beginning with either of those.) If there are, either comment them out or resolve the conflicts using the commented instructions in the file.

Save /etc/mail/aliases when you’re done editing, then run the following in the terminal:

# newaliases

Now test your config by sending an email directly to YourEmailAddress¹, checking its inbox each time:

echo "This is the body of the email" | mail -s "This is the subject line" YourEmailAddress

Then try sending an email to root:

echo "This is the body of the email" | mail -s "This is the subject line" root

Finally, try sending an email to YourUsername:

echo "This is the body of the email" | mail -s "This is the subject line" YourUsername

Those should all work.

¹ The emails I sent using this method did not have a subject line, so the -s might not work OpenIndiana. To be honest, I stole this line from Debian tutorial, so 🤷‍♂️. In any case, automated emails will have their own programmatically generated subject lines and bodies.

from jdrch https://dev.to/jdrch/how-to-set-up-email-notifications-on-openindiana-4a0f
via IFTTT

How to fix Postfix emails sent to Gmail addresses not being received

So you’ve followed the instructions to mailutils and postfix, but the test echo "This is the body of the email" | mail -s "This is the subject line" your_Gmail_address command isn’t resulting in any emails showing up at your_Gmail_address.

What’s going on? Here’s how I solved the problem (on Debian 10).

As difficult as email delivery is to set up and troubleshoot, the good news is that emails that fail to be delivered generally get bounced, and the bounced email contains useful error information.

Let’s open our inbox and see what’s there. In the terminal, run $ mail. You should see something like this (if you don’t, check your system mail logs. Doing so is outside the scope of this post):

$ mail
"/var/mail/jdrch": 1 message 1 new
>N   1 Mail Delivery Syst Sun Apr 25 14:22  70/2479  Undelivered Mail Returned to Sender

Hit Enter to read the email. Look for a line beginning with Diagnostic-Code:. In my case, the line is:

Diagnostic-Code: X-Postfix; mail for gmail.com loops back to myself

loops back here is informative. In computing terminology, looping back means that somewhere along the way a destination location resolved to the source location. In a network, e.g. email, context, those locations are typically URLs or IP addresses.

Gmail’s SMTP server URL is gmail-smtp-in.l.google.com. Let’s figure out what that resolves to using dig, which returns the IP address of input URLs resolved using the machine’s DNS settings¹:

$ dig gmail-smtp-in.l.google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> gmail-smtp-in.l.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1243
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gmail-smtp-in.l.google.com.    IN      A

;; ANSWER SECTION:
gmail-smtp-in.l.google.com. 2   IN      A       0.0.0.0

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 25 14:29:16 CDT 2021
;; MSG SIZE  rcvd: 71

In ;; ANSWER SECTION: we see that the Gmail SMTP server URL is resolving to 0.0.0.0, which always means the machine itself. So emails sent to Gmail addresses are coming right back to the source machine.

Now we know our problem is on the DNS side. It could be a DNS server, DNS filtering service, firewall, or something similar. In my case, it was 2 Pi-hole blocklists, and whitelisting the server URL fixed the issue:

$ dig gmail-smtp-in.l.google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> gmail-smtp-in.l.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19729
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gmail-smtp-in.l.google.com.    IN      A

;; ANSWER SECTION:
gmail-smtp-in.l.google.com. 599 IN      A       108.177.111.26

;; Query time: 25 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 25 14:33:09 CDT 2021
;; MSG SIZE  rcvd: 71

Aha, now ;; ANSWER SECTION: contains an IP address that at least looks more correct than 0.0.0.0 (TBH I have no idea what Google’s SMTP server IPs are.)

The echo test command at the outset now works.

from jdrch https://dev.to/jdrch/how-to-fix-postfix-emails-sent-to-gmail-addresses-not-being-received-5e17
via IFTTT

Which OpenIndiana directories to backup for bare metal recovery

For bare metal recovery, backup every ZFS filesystem under /. You can find what isn’t a ZFS filesystem by running: $ awk '$3 != "zfs" { printf("%-20s %s\n", $2, $3); }' /etc/mnttab | sort. You can also add /mnt to that list if you choose to not backup your mountpoint contents.

from jdrch https://dev.to/jdrch/which-openindiana-directories-to-backup-for-bare-metal-recovery-3a3j
via IFTTT

How to recover KDE if it doesn’t load after updating FreeBSD from 12.x to 13.0-RELEASE

You followed the official instructions to update your FreeBSD 12.x installation to 13.0-RELEASE, but now you’ve rebooted into a login: prompt. What went wrong?

The technical reason for this is there are driver changes involved in the update, and FreeBSD doesn’t appear to be able to determine which driver will work for your hardware.

To expand on that point, your existing driver type that worked in 12.x might not work in 13.0-RELEASE, but FreeBSD cannot determine which 13.0-RELEASE driver type will work for you. This means you’ll have to manually select the driver and load it into the kernel. Let’s do that.

1. Login to the FreeBSD terminal
2. # pkg update
3. # pkg upgrade
4. # pkg install drm-kmod
5. # kldload drm
6. Edit /etc/rc.conf (I prefer # nano /etc/rc.conf for that task) to comment out any existing kld_list line
7. Add the following line to /etc/rc.conf: kld_list="cuse fusefs usbhid drm"
8. If you’re in nano, press CTRL + O to save your changes
9. Hit Enter at the prompt
10. Press CTRL + X to exit nano
11. Reboot

KDE (technically SDDM) should come up at this point and you should be presented with a DE login.

The above process used a generic DRM driver. For optimal performance and functionality, you’ll need to load the driver specific to your hardware. You’ll find the driver names here. If, for example, you’re using an Intel iGPU, repeat the previous steps from the terminal within KDE, replacing drm with i915kms throughout.

Since the fix described here doesn’t reference anything KDE, it should also work for other DEs, such as Gnome, XFCE, etc.

Credit: this thread from u/grahamperrin

from jdrch https://dev.to/jdrch/how-to-recover-kde-if-it-doesn-t-load-after-updating-from-freebsd-to-12-x-to-13-0-release-1nk1
via IFTTT

How to move Microsoft OneNote 2016 (& later?) notes from one PC to another

Note: this guide applies only to OneNote 20XX notes stored locally on the PC and not synced anywhere. It cannot be guaranteed to work for synced notes and will not work for OneNote for Windows 10 notes (which are synced to OneDrive using the OneDrive client)

The whole thing is easier than you think. It should also work for OneNote versions later than 2016.

1. Open your \Documents folder
2. Open the OneNote Notebooks folder. Every subfolder in that folder is a OneNote notebook
3. Copy the desired notebook subfolder to the target PC, preferably to the default \Documents\OneNote Notebooks folder
4. On the target PC, open OneNote 2016 -> File -> Open -> Browse
5. Browse to the location of the notebook subfolder
6. Inside the notebook subfolder, select the Open Notebook.onetoc2 file
7. Click Open

This will open the copied notebook in OneNote 2016. You’ll click on each tab to populate and color them, but everything should be there.

from jdrch https://dev.to/jdrch/how-to-move-microsoft-onenote-2016-later-notes-from-one-pc-to-another-162b
via IFTTT

Fuck FreeBSD

(TL,DR: Yes, the title is hypocritical as I’m planning on deploying TrueNAS)

My dream has always been to run all major (server and desktop) OS kernel families:

1. NT (Windows) ✅
2. Unix-like ✅
   1. Linux ✅
      1. Debian
      2. Ubuntu
      3. Raspberry Pi OS
      4. Android
   2. BSD ✅
      1. FreeBSD
3. Unix ✅
   1. Illumos ✅
      1. OpenIndiana
4. UNIX™ (Coming soon)
   1. macOS

✅ = I currently run an OS kernel in this category

I’ve written before about why I might no longer run FreeBSD , but I think what has just transpired might be the last straw.

I just updated from FreeBSD 12.x-RELEASE to 13.0-RELEASE. Doing so completely broke my KDE setup, to the point that KDE won’t even launch at all.

Setting aside the fact that a major OS being unable to sustain a major version update without KOing DE functionality in 2021 is completely ridiculous, the current workaround is to build the driver from source.

Building kernel modules from source produces a whole range of problems, not the least of which are being possibly out of step with repo packages from the same source, as well as complicating future updates.

This would be totally understandable if the OS in question were an Illumos one, such as OpenIndiana, whose core dev team has only 10 people. But this is FreeBSD, the OS that supposedly underpins Netflix, PlayStation, Switch, etc.

It’s well known that FreeBSD’s dev team don’t care for DEs or the desktop use case. Now, one might argue that they aren’t listening to their users. And, if one truly believes that’s the case, then it makes sense for desktop users to run FreeBSD in the hopes that one day user demands will win out. Sure, you can use scripts to install DEs, but the problem with scripts is they tend to go out of date relatively rapidly (compared to proper ISO packages) due to having no direct upstream connection to the distribution. As such, the configs they result in are also not particularly robust.

There is no substitute for core dev team support of a feature.

Sadly, today, while visiting the FreeBSD forums to ask about my KDE woes, I discovered this thread, in which over half of the FreeBSD Forums members who voted in the OP poll indicated they had “Doubtful” or “No” interest in a FreeBSD KDE distribution.

That’s … in a word, insane. The poll has only 57 votes through nearly 4 months. That tells me pretty much no FreeBSD users are interested in this topic at all.

Clearly, there’s absolutely no hope for DEs ever being 1st class citizens in FreeBSD. Ever.

And now that I’ve recognized that truth, the reasons for me to run a FreeBSD desktop/workstation have evaporated.

Fortunately, TrueNAS exists. Unfortunately, the machine most suited to running it is currently running OpenIndiana (which since my installation thereof in 2019 has proven itself largely useless due to severe lack of package support), so I’ll probably wind up having to install OpenIndiana on my current FreeBSD machine and then throw TrueNAS on the current OpenIndiana machine.

Unfortunately, I’m not the only person to reach this conclusion with FreeBSD. The project’s devs and its community have an extremely rigid view of the distribution as a religious artifact of 1980s Berkeley software development. It sounds cute, but the problem with religious artifacts is they tend to be practically immutable (e.g. the cross, the US Constitution) even when that property is against the faith’s long term interests.

I’ve read complaints from Project Trident’s devs as well as pfSense and TrueNAS users (I’m still willing to give TrueNAS a chance because unlike many people I’m not trying to use it for VMs or jails). The bottom line is that FreeBSD is awesome right up to the point that you want it do something even minutely different from the status quo and need upstream support for that to happen. Then you get stonewalled as none of your asks, no matter how small or reasonable, are met.

So, it’s deuces, FreeBSD. Honestly it doesn’t matter if the driver bug gets fixed in the repo because thanks to the aforesaid the problem is guaranteed to repeat itself the next major version upgrade.

Clapbacks & Counterarguments

Fuck FreeBSD? FUCK YOU!

Yeah, there’s a reason I didn’t post this in a FreeBSD forum. You’re never gonna get objective criticism of a faith within a place of worship for that faith.

Installing DEs on FreeBSD is easy LOL

Unless you’re intimately familiar with how X11, windows managers, etc. all play together (which shouldn’t be necessary to use a DE in 2021), this is true only if:

1. You use a script (the 2 major ones I’m aware of are instant-workstation and desktop-installer)
2. That script is up-to-date
3. The packages that script installs are:
   1. up-to-date
   2. actually support your hardware

It has been my experience that neither 2 nor 3 can be guaranteed.

You should learn how X11, windows managers, etc. work

Nobody has time for this when macOS, any of the gazillion Linux distros with working DEs, OpenIndiana, and Windows exist.

FreeBSD is an OS for professionals

TIL professionals apparently have a lot of time to waste.

If you don’t know C, don’t use FreeBSD

So eventually no one will use FreeBSD (ever heard of Rust?) Got it.

from jdrch https://dev.to/jdrch/fuck-freebsd-2a3b
via IFTTT

How to uninstall Sysmon

Sysmon is great until you need uninstall it, in which case the documented instructions don’t work. If you get an odd the service sysmon64 is already registered, do this:

1. Stop the Sysmon service in Services.msc.
2. Open an elevated PowerShell prompt in the folder containing sysmon64.exe
3. Run sysmon64.exe -u or sysmon64.exe -u force (if the 1st command doesn’t work)

That should uninstall Sysmon completely. I’ve created a corresponding Microsoft Docs PR.

from jdrch https://dev.to/jdrch/how-to-uninstall-sysmon-npd
via IFTTT