CRThaze's questions

So I copied an SSH private key from my Linux machine to my M1 Mac. (I've attempted to do this both by uploading the cyphertext to a secrets manager as well as directly transfering the file) but when attempting to SSH to the same machine from each I can only succeed from the Linux machine.

Linux machine:

$ ssh -V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f  31 Mar 2020
$ md5sum id_rsa
7ed8b0c73e168ef48acc715d4c6bcf73  id_rsa
$ sha256sum id_rsa
969d0a35b36c50035881bdd2d8367b90dbff548131d5c72989d29e83b7a3aa19  id_rsa
$ ssh-keygen -l -f id_rsa
4096 SHA256:d19Ee+tlzVHitLzKuuZbdgYcnhla96ypXNtpBwrqfqE [email protected] (RSA)
$ ssh -i id_rsa [email protected]
[redacted MOTD; WORKS]

M1 Mac:

$ ssh -V
openSSH_8.6p1, LibreSSL 2.8.3
$ md5 id_rsa
MD5 (id_rsa) = 7ed8b0c73e168ef48acc715d4c6bcf73
$ shasum -a 256 id_rsa
969d0a35b36c50035881bdd2d8367b90dbff548131d5c72989d29e83b7a3aa19  id_rsa
$ ssh-keygen -l -f id_rsa
4096 SHA256:rWsP9jN2otlchh8icr/jlnZxDjEfEkngDJOoPh4RYZI [email protected] (RSA)
$ ssh -i id_rsa [email protected]
[email protected]: Permission denied (publickey).

AFAICT these private keys are identical. However for some reason ssh-keygen does not fingerprint them thesame. Even though they have identical checksums. Could this be an issue with the M1 SoC? Or is there something much more obvious happening here?

I have a ZFS Volume on my server I'm using as my network's NAS (called data/nas & part of the 'data' raidz zpool) and I am exposing this volume to my LAN via NFS using the ZFS attribute setting: sharenfs. This works great and has been extremely simple to manage.

I recently got an 8TB Seagate Archival SMR HDD, full of some data I would like to expose via my NAS's NFS share.

As this is an archival SMR drive, I only want to mount and expose this drive in Read-Only mode (since rewrite performance on these drives is expectedly terrible) and it is probably not a good candidate to add to ZFS (both due to the fact that it has existing and that SMR drives are not the best performers under ZFS). It's current format is UFS.

What I would like to do is mount the drive somewhere (say /mnt/foo) and then bind mount that location to a directory under my data/nas ZFS share, and thus expose the data through my existing NFS share.

I've read somewhere that setting some combination crossmnt and nohide in the sharenfs options could potentially allow this sort of relationship between two NFS exports. However, since my archival drives are not ZFS, making it too an NFS export would not be quite as simple as is possible with a ZFS volume; even if this tactic were to work.

Does anyone know if this sort of cross filesystem NFS tactic could work, especially if the mounted child filesystem is not a ZFS NFS export (or any NFS export, for that matter)? And if so, what kind of options would have to be configured to ensure reliable access to this sub-filesystem across the NAS connections?

FYI: this server is running SmartOS (Illumos) and thus has native ZFS and UFS filesystem support.

So I'm looking for a uniform way to install chef on a number of different servers running different platforms. I know I can use the omnibus installer for this, but I also need a way to lock or otherwise keep the versions consistent across machines. Is there a good way of doing this without having ruby already installed on the machines?

For example, I have two brand new servers with minimal installs. One has Ubuntu and the other has CentOS. I order one when Chef 10.12.0 is the latest and the next when 10.14.0 is the latest. I want a uniform way of installing chef on these machines and making sure that they both have chef 10.12.0 (or whichever version I specify). Does anyone have any ideas? Could I just customize the omnibus install script to accept a specific version option? Or does it already do so?