With the recent high profile Team Fortress 2 source code leak, I considered it necessary to lock down my TF2 servers as much as possible. Below is the full AppArmor profile I used to protect srcds_linux.

Complications such as SourceMod, replays and auto-update are supported. /YOUR-SRCDS-LOCATION/ and /tmp/replays should be updated as necessary.

Ran into some strange background battery drain on an iPhone SE 2nd Generation – it was noticeably above room temperature at all times (but not warm/hot to the touch), indicating a lack of deep sleep, and the battery chart showed a continuous decline, even during periods of no notifications or screen use. Additionally I received notifications suspiciously quickly – within a second of the event occurring, rather than the usual 2-5.

I say ‘unreported’ in the title as there was absolutely no indication that background drain was taking place on the Battery screen, other than in the percentage chart. ‘Screen Off’ did not exceed 30 minutes per day, and most of that was believably attributed to WhatsApp. This led me to search for system services as a cause, specifically anything I may have done that is out of the ordinary that may cause a system service to go haywire.

Couldn’t get iPhone to appear in iTunes via wi-fi sync on a Windows 10 virtual machine. Tried all the usual steps such as verifying they can ping each other, re-ticking ‘sync with this iPhone over wi-fi’, rebooting, terminating AppleMobileDeviceHelper, etc.

Was getting the ‘operation not supported’ error when trying to connect to a Linux samba server from the iOS 13 Files app.

Fixed by setting min protocol = SMB2 in smb.conf (previously was set to SMB3)

Short answer: Yes.

As I continue to develop a software solution to the problem described in https://darkimmortal.com/lto4-encryption-woes/, I have come across some bits of information about the inner workings of the LTO-4 on-tape format that are undocumented on the public internet.

In my experience, LTO-4 tapes encrypted with IBM drives can be read on HP drives, but not vice-versa. The IBM drive I have hangs and resets the SCSI bus when attempting to decrypt a HP encrypted tape.

I’ve tried a ridiculous number of combinations of SCSI parameters to the encryption, decryption and read. I’ve also tried all available firmwares for both drives.

However IBM drives will happily read the raw data, so my current weekend project is to try and reverse engineer and decrypt this in software. Update: Finished! https://github.com/lukefor/ltoex – more info here: https://darkimmortal.com/the-secrets-of-lto-tape/

So much for LTO being a compatible and open standard!

All over the internet I’ve seen reports of APFS conversion issues:

• An internal error occurred while preflighting your volume for APFS
• APFS converter preflight returned 6
• APFS converter exit code is 1
• Exiting conversion operations with exit code -69860

But no one has solved the issue without the nuclear option of a fresh install.

Recently I had the task of recovering files from a 1TB hard disk in an iMac that was on its last legs – bad sectors, clicking and would not boot. Many passes, especially in reverse, of ddrescue saved all but 8 sectors.

Bought a Tandberg Data Full-Height external LTO 4 drive (1640LTO, 7202) with SCSI connection and was disappointed to find it did not support encryption. Stenc refused to do anything, and it matched the behaviour from this article with the raw SCSI commands: https://www.stroppykitten.com/technical/fun-with-scsi-tapes

# stenc -f /dev/nst0 --detail
Status for /dev/nst0
--------------------------------------------------
Device Mfg:              IBM     
Product ID:              ULTRIUM-TD4     
Product Revision:        74H6
Sense Code:              Illegal Request (0x05)
 ASC:                    0x24
 ASCQ:                   0x00