Update to this story at 20 Feb 2018: I’ve been debugging the problem together with Apple and I feel like we are closing in on a solution. My current guess is that Finder indexing needs a lot more time on High Sierra than on Sierra clients. Update to this story at 6 July 2018: I’ve […]
encode: $ openssl base64 -in base64.decoded.txt -out base64.encoded.txt decode: $ openssl base64 -d -in base64.encoded.txt -out base64.decoded.txt
run: $ grep flags /proc/cpuinfo if you see a lm flag, this means Long mode cpu = 64 bit CPU
1. Local: ssh-keygen scp ~/.ssh/*.pub username@remote: ssh username@remote 2. Remote mkdir .ssh cat ~/*.pub >> ~/.ssh/authorized_keys rm *.pub chmod 644 ~/.ssh/authorized_keys -or- Script it like this: ssh-keygen scp ~/.ssh/*.pub user@remote:`uname -n`.pub ssh user@remote “cat ~/*.pub >> ~/.ssh/authorized_keys” ssh user@remote “rm ~/*.pub”
get three network cards, two for the bridge, mine are re0, em0 & em1 (re0 = admin connection to serve sshd) echo ‘dhcp’ > /etc/hostname.re0 echo ‘up’ > /etc/hostname.em0 echo ‘up’ > /etc/hostname.em1 echo ‘add em0’ > /etc/hostname.bridge0 echo ‘add em1’ >> /etc/hostname.bridge0 echo ‘blocknonip em0’ >> /etc/hostname.bridge0 echo ‘blocknonip em1’ >> /etc/hostname.bridge0 echo ‘up’ […]
Here’s a odd one, on one of my networks, I discovered this flowing around: 09:56:02.660795 arp who-has 192.168.30.32 (ff:ff:ff:ff:ff:ff) tell 192.168.30.32 (even though i’m not in this subnet) For those of you who have seen this, it’s called a Gratuitous ARP and originates from an IPMI enabled nic (Intel’s IPMI = Intelligent Platform Management Interface) […]