Normal view

There are new articles available, click to refresh the page.
Yesterday — 29 May 2026Main stream

What happens in the log when an app crashes as it starts up?

By: hoakley
29 May 2026 at 14:30

In yesterday’s guide to dealing with apps that crash immediately you open them, I carefully avoided mentioning what you might find in the log. This article puts that right.

The list of common causes I gave is:

  • macOS intentionally crashed the app because of an error in code signing, or another serious security failure;
  • the app failed because it was in translocation;
  • the app couldn’t open a damaged or incompatible document;
  • the app had a problem with its Preferences.

Investigating these in the log is among the simplest tasks for those learning to access it, providing the app crashes reliably. Show the seconds value in the menu bar clock, and open the Applications folder containing the app. Select it as the seconds reach about 45, to allow time for its icon to be displayed, then double-click the app to run it as the seconds reach 00, but not a moment earlier. Don’t touch the mouse/trackpad or keyboard for at least 5 seconds, by which time the crash should have occurred and the notification or crash log should have been displayed.

Then open LogUI (or a substitute), and set it to extract and display all the entries for 5 seconds from 00 seconds. If you open a new window in LogUI the start time will be preset to the time you opened the app, all ready to get the log extract.

The double-click is easy to spot in the log, as it’s marked by four almost identical Activity entries with a yellow 🥎 softball emoji, each reading something like
AppKit Finder sendAction:
short entries that are quick to locate. Entries following the fourth of those then report what happened next.

Code signing errors

These are normally easy to recognise, as they start with a call to verify the signature,
00.940943 Finder sendAction:
00.963228 syspolicyd SecTrustEvaluateIfNecessary
00.963982 trustd SecKeyVerifySignature

that’s followed by an error that’s repeated many times,
00.981296 lsd com.apple.securityd MacOS error: -67030

Follow those down a bit further and you’ll see this reported in other subsystems
01.013084 com.apple.launchservices Error -67030 validating the signing information for [private], error=Error Domain=NSOSStatusErrorDomain Code=-67030 "(null)" UserInfo={SecCSArchitecture=arm64}

Normally, this will be checked again by AMFI (Apple Mobile File Integrity)
01.030162 amfid Entering OSX path for /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd
01.031629 amfid SecKeyVerifySignature
01.036291 amfid com.apple.securityd MacOS error: -67030
01.048491 error amfid com.apple.MobileFileIntegrity.framework Code failed basic validity check (error: -67030): Error Domain=NSOSStatusErrorDomain Code=-67030 UserInfo={SecCSArchitecture=[private]}
01.048857 amfid /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" UserInfo={NSURL=file:///Users/hoakley/Documents/
000aa/DelightEd.app/Contents/MacOS/DelightEd, NSLocalizedDescription=The signature on the file is invalid}

That’s confirmed and actioned by the kernel
01.048950 kernel AMFI: code signature validation failed.
01.052968 amfid com.apple.MobileFileIntegrity [private]: Broken signature with Team ID fatal.
01.053043 kernel AMFI: When validating /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd: The code contains a Team ID, but validating its signature failed. Please check your system log.
01.053052 kernel mac_vnode_check_signature: /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd: code signature validation failed fatally: When validating /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd: The code contains a Team ID, but validating its signature failed. Please check your system log.
01.053059 kernel validation of code signature failed through MACF policy: 1
01.053061 kernel check_signature[pid: 2718]: error = 1
01.053066 kernel proc 2718: load code signature error 4 for file "DelightEd"
01.053461 kernel AMFI: hook..execve() killing xpcproxy (pid 2718): Attempt to execute completely unsigned code (must be at least ad-hoc signed).
01.053624 kernel ASP: Sleep interrupted: ref 29, signal 0x100, pid: 2718

with the conclusion
01.053627 kernel ASP: Security policy would not allow process: 2718, /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd

You’re not likely to miss those.

Common error codes from signature validation include:

  • -2147409652 CSSMERR_TP_CERT_REVOKED, the certificate has been revoked
  • -67007 resource envelope is obsolete (version 1 signature)
  • -67008 unsealed contents present in the root directory of an embedded framework
  • -67013 resource envelope is obsolete (custom omit rules)
  • -67021 nested code is modified or invalid
  • -67023 invalid resource directory (directory or signature have been modified)
  • -67030 invalid Info.plist (plist or signature have been modified)
  • -67054 a sealed resource is missing or invalid
  • -67056 code has no resources but signature indicates they must be present
  • -67061 invalid signature (code or signature have been modified)
  • -67062 code object is not signed at all, which is by far the most common.

In this case, I had changed a single character in the app’s Info.plist, which broke its CDHashes, and resulted in the correct error code of -67030.

App translocation

In this case, you’re looking for two related pieces of evidence, that a process mentions the act of translocation, and that the app is run from a translocation location. Again, these normally aren’t hard to find.

Shortly after the double-click,
00.968186 Finder sendAction:
you should see mention of the creation of the translocation directory
01.040587 lsd com.apple.securityd SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/x4/
x00kny5x0_5dsnmmxhtw6hc80000gn/T/AppTranslocation/B9651238-6B8C-4750-BFAC-E0D1A327768C/d/DelightEd.app

A little further down the log you’ll see the app being referenced in that long path
01.069877 amfid Entering OSX path for /private/var/folders/x4/x00kny5x0_5dsnmmxhtw6hc80000gn/T/AppTranslocation/
B9651238-6B8C-4750-BFAC-E0D1A327768C/d/DelightEd.app/Contents/MacOS/DelightEd
01.090927 com.apple.runningboard _executablePath = /private/var/folders/x4/x00kny5x0_5dsnmmxhtw6hc80000gn/T/AppTranslocation/
B9651238-6B8C-4750-BFAC-E0D1A327768C/d/DelightEd.app/Contents/MacOS/DelightEd

and so on.

If you’re struggling to find those, select the Messages item at the right end of the toolbar in LogUI, type the app name into the search box there and press Return, to filter entries.

Failed to open document

Of the four common causes of early app crashes, these are hardest to find evidence in the log. This is because the only process likely to know what went wrong is the app itself, and few third-party apps write anything useful to the log. You might find a useful entry or two by setting that menu at the right end of LogUI’s toolbar to Processes, entering the app name into the search box, and pressing Return. However, in many cases there will be little or no useful information.

Preference file problems

My previous article referred only to standard preferences that are handled by cfprefsd. Some apps run their own preferences using their own code, and neither cfprefsd nor the defaults command covers them. If they have a problem when accessing those custom files, it’s most unlikely to be recorded in the log.

In other apps, you should look for evidence that the crash happened shortly after the cfprefsd service is connected to the app, to support the standard features.

Starting once again with the double-click
01.579559 Finder sendAction:
it may take some time for the opening stages to complete. You should then see the XPC connection between the app and cfprefsd being set up for both root and the user
01.638428 DelightEd com.apple.xpc [0x102cf6980] activating connection: mach=true listener=false peer=false name=com.apple.cfprefsd.daemon
01.638504 DelightEd com.apple.xpc [0x102cf7960] activating connection: mach=true listener=false peer=false name=com.apple.cfprefsd.agent
01.638563 cfprefsd com.apple.xpc [0xa252bdb00] activating connection: mach=false listener=false peer=true name=com.apple.cfprefsd.daemon.peer[2910].0xa252bdb00
01.638659 cfprefsd com.apple.xpc [0x86f2d3600] activating connection: mach=false listener=false peer=true name=com.apple.cfprefsd.agent.peer[2910].0x86f2d3600

The app will normally crash during or shortly after the loading of preferences, marked by entries like
01.641152 DelightEd Loading Preferences From User CFPrefsD
01.706158 DelightEd Loading Preferences From System CFPrefsD

These too can be found more easily by setting the menu at the right end of LogUI’s toolbar to Processes, entering the app name into the search box, and pressing Return.

Happy hunting!

Before yesterdayMain stream

Tackle QuickLook problems

By: hoakley
20 May 2026 at 14:30

With an understanding of how QuickLook provides thumbnails and previews, you can be systematic when tackling its problems, although thankfully those are infrequent if not rare.

Generic icon

By far the most common problem with QuickLook thumbnailing is when a file’s specific thumbnail isn’t shown, but a generic icon for that type of file appears instead. This has been particularly common since the release of macOS Sequoia, as that ended support for older third-party generators in qlgenerators. To be able to extend the range of types supported by thumbnailing, third-party generators must now be supplied as appexes stored in an app bundle’s PlugIns folder or similar.

To pin this down, you’ll first need to discover the UTI of the files whose icons can no longer be turned into specific thumbnails. One easy way to do that is in my free UTIutility. Type in the file’s extension, press Return and the app will tell you that file’s UTI and those it conforms to.

utilutil121

You next need to discover which generator handles those UTIs. The official way to do that is using the command
qlmanage -m
but that now only lists qlgenerators supplied in macOS, as qlgenerators. To see listings of others as well, open my free Mints and click on its QuickLook button.

mints1202

For qlgenerators, you’re given the file UTI, the path to the qlgenerator file, and (when available) its version number, e.g.
com.adobe.pdf 👉/System/Library/QuickLook/PDF.qlgenerator (1002.2.3)

App extensions are divided into two, first those providing Previews, and second those for Thumbnails, e.g.
com.apple.applescript.text 👉/Applications/PreviewCode.app/Contents/PlugIns/Code Previewer.appex

If no generator handles the file’s UTI, ascend the list of UTIs it conforms with to discover which generator should attempt to. If you think an old qlgenerator is the problem now, contact the app’s developer and ask whether they intend supporting macOS with an appex replacement.

Occasionally you may come across an extension conflict, in which the same extension is used for another UTI, resulting in the wrong generator trying to create a thumbnail.

The nuclear option for any QuickLook problem is to reset its caches, using the command
qlmanage -r

Although its effects might be to slow thumbnail generation for a while, it’s unlikely to prove any more damaging.

Digging deeper

If you have to go any deeper than that, you’re going to need to capture good log extracts to enable diagnosis. As far as Icon Services, QuickLook and related features are concerned, it’s essential to disable log privacy before going any further, or you’ll be driven crazy by all those messages gutted and rendered meaningless by censorship.

Even then, log entries refer to key items such as files and folders using references that may appear opaque. Some abbreviate file names and directories as ‘B{14}1.jpg’ for BeltedGalloways1.jpg, and ‘t{5}s’ for testims, as well as referring to them by hex numbers like 0xBBDBEFDB0. Another common habit in log entries is to refer to files by their inode number, either as an ino, or in a full URL such as file:///.file/id=6571367.243284. The use of UUIDs is also common, for example as uuid:0AD8986E-6325-4FF1-92FD-9FD3C15D57EA.

Example thumbnail generation

This was initiated by a mouse click, following which a thumbnail isn’t immediately available from cache.

01.008113 Finder sendAction:
01.012218 com.apple.Finder | ThumbnailCache (0xbbe43cfd8, kIconified) -- Retrieve: 'B{14}1.jpg' (0xBBDBEFDB0), Container: 't{5}s' (0xBBD6F1C00), found: no
01.015014 QuickLookThumbnailingDaemon com.apple.quicklook | Enqueuing thumbnail request: <QLTGeneratorThumbnailRequest: <QLThumbnailGenerationRequest:0xc34e526c0 uuid:0AD8986E-6325-4FF1-92FD-9FD3C15D57EA BeltedGalloways1.jpg (fi:<fi:<QLCacheBasicFileIdentifier:0xc35297760 ino:243284> (version: <QLThumbnailVersion m:2019-01-28 12:36:40 +0000 s:656575 vi:{length = 12, bytes = 0x54b603000000000002000000} ino:3b654 g:com.apple.MobileQuickLook-1>)>) (rt:2) {16,16} (icon mode, variant 0) (badge 1) - Not started>, url: (null), item: (null), ht:0 bt:0 (low quality) client:com.apple.finder>
01.015016 QuickLookThumbnailingDaemon Cache Lookup

Following that are entries for memory and disk cache lookup, also resulting in failure, so the thumbnail has to be generated.

01.015626 QuickLookThumbnailingDaemon com.apple.quicklook | Enqueuing thumbnail request: <QLTGeneratorThumbnailRequest: <QLThumbnailGenerationRequest:0xc34e526c0 uuid:0AD8986E-6325-4FF1-92FD-9FD3C15D57EA BeltedGalloways1.jpg (fi:<fi:<QLCacheBasicFileIdentifier:0xc35297760 ino:243284> (version: <QLThumbnailVersion m:2019-01-28 12:36:40 +0000 s:656575 vi:{length = 12, bytes = 0x54b603000000000002000000} ino:3b654 g:com.apple.quicklook.thumbnail.ImageExtension-1>)>) (rt:2) {16,16} (icon mode, variant 0) (badge 1) - Not started>, url: (null), item: (null), ht:0 bt:0 (low quality) client:com.apple.finder>
01.017045 QuickLookThumbnailingDaemon com.apple.quicklook | <QLTGeneratorThumbnailRequest: <QLThumbnailGenerationRequest:0xc34e526c0 uuid:0AD8986E-6325-4FF1-92FD-9FD3C15D57EA BeltedGalloways1.jpg (fi:<fi:<QLCacheBasicFileIdentifier:0xc35297760 ino:243284> (version: <QLThumbnailVersion m:2019-01-28 12:36:40 +0000 s:656575 vi:{length = 12, bytes = 0x54b603000000000002000000} ino:3b654 g:com.apple.quicklook.thumbnail.ImageExtension-1>)>) (rt:2) {16,16} (icon mode, variant 0) (badge 1) - Not started>, url: file:///Users/howardoakley/Documents/testims/BeltedGalloways1.jpg, item: (null), ht:0 bt:0 (low quality) client:com.apple.finder> is downloaded. Trying to generate a thumbnail locally
01.017054 QuickLookThumbnailingDaemon com.apple.quicklook | About to generate a thumbnail locally from URL: file:///Users/howardoakley/Documents/testims/BeltedGalloways1.jpg

This leads to the file’s UTI type being looked up in the dictionary of those known to be handled by bundled qlgenerators. These are the log entries most important to those hunting generator problems.

01.017971 QuickLookSupport com.apple.quicklook | No exact match found in type dictionary 0xc352a7ae0 for 'public.jpeg' #UTI
01.018010 QuickLookSupport com.apple.quicklook | Getting 5 for 'icon flavor' from UTI 'public.image' #UTI
01.018012 QuickLookSupport com.apple.quicklook | Getting 5 for 'icon flavor' from UTI 'public.jpeg' #UTI
01.018765 QuickLookThumbnailingDaemon com.apple.quicklook | Generating thumbnail for <QLThumbnailItem: 0xc351c36c0> (size (16.0, 16.0)) with badge type 1 with extension <QLThumbnailExtension: 0xc354ec540>

That thumbnail is then entered into the store and its index.

01.036504 IconServices com.apple.iconservices | ADDING_NEW_STORE_ENTRY with UUID: FEE02B54-EE08-3F1F-90BD-8A8105536419
01.037902 iconservicesagent com.apple.iconservices | ADDED_INDEX_ITEM: B1F5E967-57DC-3A3E-9459-8DE0C14862C3
01.118704 QuickLookThumbnailingDaemon com.apple.quicklook | completing thumbnail request <QLTGeneratorThumbnailRequest: <QLThumbnailGenerationRequest:0xc34e526c0 uuid:0AD8986E-6325-4FF1-92FD-9FD3C15D57EA BeltedGalloways1.jpg (fi:<fi:<QLCacheBasicFileIdentifier:0xc35297760 ino:243284> (version: <QLThumbnailVersion m:2019-01-28 12:36:40 +0000 s:656575 vi:{length = 12, bytes = 0x54b603000000000002000000} ino:3b654 g:com.apple.quicklook.thumbnail.ImageExtension-1>)>) (rt:2) {16,16} (icon mode, variant 0) (badge 1) - Not started>, url: file:///Users/howardoakley/Documents/testims/BeltedGalloways1.jpg, item: (null), ht:0 bt:0 (low quality) client:com.apple.finder> in addImageData

Full details are given of the thumbnail, here 32 x 32 pixels in size, as it was for a Column view entry.

01.118961 Finder com.apple.quicklook | Received thumbnail for <QLThumbnailGenerationRequest:0xbbbafc280 uuid:0AD8986E-6325-4FF1-92FD-9FD3C15D57EA BeltedGalloways1.jpg (fi:<fi:<QLCacheBasicFileIdentifier:0xbbe83fd80 ino:243284> (version: <QLThumbnailVersion m:2019-01-28 12:36:40 +0000 s:656575 vi:{length = 12, bytes = 0x54b603000000000002000000} ino:3b654 g:com.apple.MobileQuickLook-1>)>) (rt:2) {16,16} (icon mode, variant 0) (badge 1) - Running>: data of length 16384, bitmap format <QLTBitmapFormat 0xbbb8c0000 s=(32, 32) bpc=8 bpp=32 bpr=128 i=8194>, error (null), image <CGImage 0xbbeb25cc0> (DP)
<<CGColorSpace 0x101cf85c0> (kCGColorSpaceICCBased; kCGColorSpaceModelRGB; sRGB IEC61966-2.1)>
headroom = 1.000000
width = 32, height = 32, bpc = 8, bpp = 32, row bytes = 128,
kCGImageAlphaPremultipliedFirst | kCGImageByteOrder32Little | kCGImagePixelFormatPacked
is mask? No, has masking color? No, has soft mask? No, has matte? No, should interpolate? Yes
01.119034 QuickLookThumbnailing com.apple.quicklook | Calling request completionBlock for <QLThumbnailGenerationRequest:0xbbbafc280 uuid:0AD8986E-6325-4FF1-92FD-9FD3C15D57EA BeltedGalloways1.jpg (fi:<fi:<QLCacheBasicFileIdentifier:0xbbe83fd80 ino:243284> (version: <QLThumbnailVersion m:2019-01-28 12:36:40 +0000 s:656575 vi:{length = 12, bytes = 0x54b603000000000002000000} ino:3b654 g:com.apple.MobileQuickLook-1>)>) (rt:2) {16,16} (icon mode, variant 0) (badge 1) - Finished> without error.

01.119873 QuickLookThumbnailing com.apple.quicklook | Thumbnail generation duration of 0.106 for <QLThumbnailGenerationRequest:0xbbbafc280 uuid:0AD8986E-6325-4FF1-92FD-9FD3C15D57EA BeltedGalloways1.jpg (fi:<fi:<QLCacheBasicFileIdentifier:0xbbe83fd80 ino:243284> (version: <QLThumbnailVersion m:2019-01-28 12:36:40 +0000 s:656575 vi:{length = 12, bytes = 0x54b603000000000002000000} ino:3b654 g:com.apple.MobileQuickLook-1>)>) (rt:2) {16,16} (icon mode, variant 0) (badge 1) - Finished>. Most representative thumbnail generated: <QLThumbnailRepresentation:0xbbea1c120 type: Thumbnail; properties=inlinePreviewMode: 1; baseline 9223372036854775807; props = {
}>

01.124730 QuickLookThumbnailingDaemon com.apple.quicklook | Thumbnail extension generated thumbnail for <QLFileThumbnailRequest:0xc352d6210 maximumSize=(16.00, 16.00) minimumSize=(0.00,0.00) scale=2.0 item=<QLThumbnailItem: 0xc351c3940>>: reply = <QLThumbnailReply: 0xc351e4600> type:0, error = (null)
01.124744 QuickLookThumbnailingDaemon com.apple.quicklook | Operation did finish for <QLFileThumbnailRequest:0xc352d6210 maximumSize=(16.00, 16.00) minimumSize=(0.00,0.00) scale=2.0 item=<QLThumbnailItem: 0xc351c3940>>
01.124784 QuickLookSupport com.apple.quicklook | Getting 5 for 'icon flavor' from UTI 'public.jpeg' #UTI

Once in the Thumbnail Cache, loading should be very quick, typically around 0.0001 seconds from start to the thumbnail being set as displayable.

Example missing generator

This shows some of the salient log entries made when a file type doesn’t have a generator available, in this case for an IconComposer icon file.

This is most obvious from UTI dictionary lookup

00.690352 QuickLookThumbnailingDaemon com.apple.quicklook | About to generate a thumbnail locally from URL: file:///Users/howardoakley/Documents/mints%20icon/Mints.icon/
00.690897 QuickLookSupport com.apple.quicklook | No exact match found in type dictionary 0xb933cfce0 for 'com.apple.iconcomposer.icon' #UTI
00.690957 QuickLookSupport com.apple.quicklook | No exact match found in type dictionary 0xb933cfce0 for 'com.apple.package' #UTI
00.691040 QuickLookSupport com.apple.quicklook | No exact match found in type dictionary 0xb933cfce0 for 'public.directory' #UTI
00.691092 QuickLookSupport com.apple.quicklook | No exact match found in type dictionary 0xb933cfce0 for 'public.item' #UTI
00.691098 QuickLookSupport com.apple.quicklook | Caching NSNULL as icon flavor for 'public.item' #UTI
00.691100 QuickLookSupport com.apple.quicklook | Caching NSNULL as icon flavor for 'public.directory' #UTI
00.691101 QuickLookSupport com.apple.quicklook | Caching NSNULL as icon flavor for 'com.apple.package' #UTI
00.691102 QuickLookSupport com.apple.quicklook | Caching NSNULL as icon flavor for 'com.apple.iconcomposer.icon' #UTI
00.691797 QuickLookThumbnailingDaemon com.apple.quicklook | Generating thumbnail for <QLThumbnailItem: 0xb92e10500> (size (16.0, 16.0)) with badge type 1 with extension <QLThumbnailExtension: 0xb934000e0>

The resulting error refers to the missing generator, not the file whose thumbnail is being generated.

00.769110 error QuickLookThumbnailing com.apple.quicklook | Generation error for request <QLFileThumbnailRequest:0x8cb0a8140 maximumSize=(16.00, 16.00) minimumSize=(0.00,0.00) scale=2.0 item=<QLThumbnailItem: 0x8cb014dc0>> : Error Domain=NSCocoaErrorDomain Code=260 "The file couldn’t be opened because it doesn’t exist."

The solution is to generate a placeholder icon as the ‘most representative’.

00.771382 QuickLookThumbnailing com.apple.quicklook | Thumbnail generation duration of 0.093 for <QLThumbnailGenerationRequest:0xbce54aa80 uuid:E33D448A-849E-4CCA-8543-5F6B9DB532D9 Mints.icon (fi:<fi:<QLCacheBasicFileIdentifier:0xbcf48dc60 ino:254169> (version: <QLThumbnailVersion m:2025-06-17 12:42:50 +0000 s:0 vi:{length = 12, bytes = 0xd9e003000000000003000000} ino:3e0d9 g:com.apple.MobileQuickLook-1>)>) (rt:2) {16,16} (icon mode, variant 0) (badge 1) - Finished>. Most representative thumbnail generated: (null)

When that is accessed later for use in the Preview pane, that’s made clear.

02.773702 Finder com.apple.AppKit | ISImage reported a placeholder, image rep is providing a placeholder image for <ISBundleIcon 0xbd0165d10> Bundle URL: file:///System/Library/CoreServices/Finder.app/ type: (null) tag: (null) tag class: (null) digest:96BABFB5-FBB5-0662-25FA-99CA1A147F30

Once the generator has been made available, in this case by running the IconComposer app for the first time, it can be used to generate a thumbnail and preview. Note this requires the appex to be launched first.

02.409348 QuickLookSupport com.apple.quicklook | No exact match found in type dictionary 0xbd01fcf00 for 'com.apple.iconcomposer.icon' #UTI
02.409406 QuickLookSupport com.apple.quicklook | Getting <QLGenerator Package.qlgenerator> for 'Generator' from UTI 'com.apple.package' #UTI
02.409408 QuickLookSupport com.apple.quicklook | Getting <QLGenerator Package.qlgenerator> for 'Generator' from UTI 'com.apple.iconcomposer.icon' #UTI
02.676198 ExtensionFoundation com.apple.extensionkit | Extension `/Applications/Icon Composer.app/Contents/PlugIns/Icon Composer QuickLook Preview.appex/Contents/MacOS/Icon Composer QuickLook Preview` of type: `` launched.

To see almost all these log entries if you’re using LogUI, fetch all the entries for the period in question, then use its Search feature to display only those with a subsystem of com.apple.quicklook.

Control what gets written to the log

By: hoakley
30 April 2026 at 14:30

One of the first things that strikes you when you look at a log extract from a Mac, is the number of entries that have some or all of their contents censored with <private>. Another is the sheer number of entries; even when your Mac is doing little, there’s a constant stream of them. This article explains how you can get control of both.

Logging preferences

The keys to controlling what gets written to the log in macOS are property lists stored inside /Library/Preferences/Logging. By default you’re likely to see few files there, which may include a high-level policy in com.apple.system.logging.plist. If present, that’s likely to set just two keys, Enable-Logging to true, and Locked to true as well. But that property list doesn’t tell the whole story.

To discover full top-level policy, you need to enter the command
sudo log config --status
which is likely to return
System mode = INFO

Step one down from there with
sudo log config --status --subsystem com.apple.system.logging
and that might report
INFO PERSIST_DEFAULT
or could extend to include
SIGNPOST_PERSISTED_OFF SIGNPOST_ENABLED_ON SIGNPOST_BACKTRACE_ENABLED_OFF OVERSIZE_ENABLED_OFF
as well.

Now try a more specific subsystem with
sudo log config --status --subsystem com.apple.network
and you’re likely to see something similar, unless there’s a property listed named com.apple.network.plist in the Subsystems folder there, in which case it should reflect the settings in that.

Those settings largely concern two features:

  • Levels of log entry recorded, set as default, info or debug. The first of those includes all entries of default or higher level, the second of info, default or higher, and the third of debug, info, default or higher. Default global level is normally info, so that debug entries don’t appear in the log.
  • Whether the entries are saved to persistent storage (disk), using the same hierarchy of levels.

Thus INFO PERSIST_DEFAULT means that all log entries of info level and above, but not debug, will be collected, and the default setting is used to determine which get written to disk.

Apple explains those basic settings in man log, and its documentation for developers.

Signpost and Oversize settings aren’t explained there, but are in man 5 os_log. Signpost log entries are intended for use by developers to assess performance, and are rarely of any use to others. Oversize log entries can be many pages long, and are stored separately when enabled.

Controlling logging preferences

There are three ways to control logging preferences, which all converge on those same property lists:

  • The log config command, as used above. This is quick and simple, but limited, and perhaps best used to check effective settings for individual subsystems and processes.
  • Write your own property lists and install them in the appropriate folder in /Library/Preferences/Logging. Although this is powerful, as there’s limited guidance on what can be included, you’ll probably want to start from existing property lists. There’s further information in Peter Steinberger’s post and man 5 os_log.
  • Install a custom log profile, which you can also use as a model to develop your own property lists and profiles.

Custom logging preferences take effect almost immediately, and don’t require restarting, but they only apply to log entries written once they have been applied, never retrospectively.

Limiting log entries by level

As the Unified log discards old log entries to constrain the space occupied by the logs, the only way to extend the period covered by stored log entries is to limit the rate at which fresh entries are added to the log. You can do this by careful assessment of which subsystems are writing most entries, and changing their logging preferences.

However, that only applies when there’s an excess of log entries at debug or info levels. When there is, adding or modifying the preferences for that subsystem to store entries at a level of default or info should extend the period they cover. Be cautious, though: that excess of entries could reflect a problem, and by excluding them you may well conceal its cause and extent.

Custom log profiles

The simplest alternative is to install a Configuration Profile containing the saved settings to be applied to the property lists in /Library/Preferences/Logging. I provide a signed profile to remove all that <private> censorship in enablelogprivatedata.

To install the profile unzip the archive into a convenient folder and double-click it. You’ll be prompted to review the profile to install it.

Open System Settings > General & Device Management, and inspect it by double-clicking the profile there.

Click on the Install button to accept and install the profile.

To remove it, select the profile and click the – tool below.

If you watch the contents of com.apple.system.logging.plist in /Library/Preferences/Logging you’ll see that change, with the setting of the key Enable-Private-Data to true. If you then run
sudo log config --status
with that profile installed, it should report something like
System mode = INFO PRIVATE_DATA
to confirm that private data is being shown in log entries, and that’s the best way to gain access to their full contents. Remember to remove the profile as soon as you’re done, or your log will continue to leak sensitive data.

There’s a collection of custom log profiles to gather log extracts about specific features in macOS (and Apple’s other OSes). Although they’re listed here, you can only download them if you have a developer (or equivalent) account with Apple. What’s more, Apple describes these as confidential, and explicitly forbids their use or disclosure without its permission. So much as I’d love to explain the undocumented features they use, I regret that I can’t.

Why you can’t trust Privacy & Security

By: hoakley
10 April 2026 at 14:30

In this Friday’s magic demonstration, I’m going to show how what you see in Privacy & Security settings can be misleading, when it tells you that an app doesn’t have access to a protected folder, but it really does.

Although it appears you can achieve this using several ordinary apps, to make things simpler and clearer I’ve written a little app for this purpose, Insent, available from here: insent11

I’m working in macOS Tahoe 26.4, but I suspect you should see much the same in any version from macOS 13.5 onwards, as supported by Insent.

For this magic demo, I’m only going to use two of Insent’s six buttons:

  • Open by consent, which results in Insent choosing a random text file from the top level of your Documents folder, and displaying its name and the start of its contents below. As it does this without involving the user in the process, the macOS privacy system TCC requires it to obtain the user’s consent to list and access the contents of that protected folder.
  • Open from folder, which opens an Open and Save Panel where you select a folder. Insent then picks a random text file from the top level of that folder, and displays its name and the start of its contents below. Because you expressed your intent to access that protected folder, TCC considers that is good enough to give access without requiring any consent.

Demonstration

Once you have downloaded Insent, extracted it from its archive, and dragged the app from that folder into one of your Applications folders, follow this sequence of actions:

  1. Open Insent, click on Open by consent, and consent to the prompt to allow it to access your Documents folder. Shortly afterwards, Insent will display the opening of one of the text files in Documents. Quit Insent.
  2. Open Privacy & Security settings, select Files & Folders, and confirm that Insent has been given access to Documents.
  3. Open Insent, click on Open by consent, and confirm it now gains access to a text file without asking for consent. Quit Insent.
  4. Open Privacy & Security settings, select Files & Folders, and disable Documents access in Insent’s entry there using the toggle.
  5. Open Insent, click on Open by consent, and confirm that it can no longer open a text file, but displays [Couldn't get contents of Documents folder].
  6. Click on Open from folder and select your Documents folder there. Confirm that works as expected and displays the name and contents of one of the text files in Documents.
  7. Click on Open by consent, and confirm that now works again.
  8. Confirm that Documents access for Insent is still disabled in Files & Folders.
  9. Whatever you do now, the app retains full access to Documents, no matter what is shown or set in Files & Folders.

Indeed, the only way you can protect your Documents folder from access by Insent is to run the following command in Terminal:
tccutil reset All co.eclecticlight.Insent
then restart your Mac. That should set Insent’s privacy settings back to their default.

You can also demonstrate that this behaviour is specific to one protected folder at a time. If you select a different protected folder like Desktop or Downloads using the Open from folder button, then Insent still won’t be able to list the contents of the Documents folder, as its TCC settings will function as expected.

How does this work?

Insent is an ordinary notarised app, and doesn’t run in a sandbox or pull any clever tricks. When System Integrity Protection (SIP) is enabled some of its operations are sandboxed, though, including attempts to list or access the contents of locations that are protected by TCC.

When you click on its Open by consent button, sandboxd intercepts the File Manager call to list the contents of Documents, as a protected folder. It then requests approval for that from TCC, as seen in the following log entries:
1.204592 Insent sendAction:
1.205160 Insent: trying to list files in ~/Documents
1.205828 sandboxd request approval
1.205919 sandboxd tcc_send_request_authorization() IPC

TCC doesn’t have authorisation for that access by Insent, either by Full Disk Access or specific access to Documents, so it prompts the user for their consent. If that’s given, the following log entries show that being passed back to the sandbox, and the change being notified to com.apple.chrono, followed by Insent actioning the original request:
3.798770 com.apple.sandbox kTCCServiceSystemPolicyDocumentsFolder granted by TCC for Insent
3.802225 com.apple.chrono appAuth:co.eclecticlight.Insent] tcc authorization(s) changed
3.809558 Insent: trying to look in ~/Documents for text files
3.809691 Insent: trying to read from: /Users/hoakley/Documents/asHelp.text
3.842101 Insent: read from: /Users/hoakley/Documents/asHelp.text

If you then disable Insent’s access to Documents in Privacy & Security settings, TCC denies access to Documents, and Insent can’t get the list of its contents:
1.093533 com.apple.TCC AUTHREQ_RESULT: msgID=440.109, authValue=0, authReason=4, authVersion=1, desired_auth=0, error=(null),
1.093669 com.apple.sandbox kTCCServiceSystemPolicyDocumentsFolder denied by TCC for Insent
1.094007 Insent: couldn't get contents of ~/Documents

If you then access Documents by intent through the Open and Save Panel, sandboxd no longer intercepts the request, and TCC therefore doesn’t grant or deny access:
0.897244 Insent sendAction:
0.897318 Insent: trying to list files in ~/Documents
0.900828 Insent: trying to look in ~/Documents for text files
0.901112 Insent: trying to read from: /Users/hoakley/Documents/T2M2_2026-01-06_13_03_00.text
0.904101 Insent: read from: /Users/hoakley/Documents/T2M2_2026-01-06_13_03_00.text

Thus, access to a protected folder by user intent, such as through the Open and Save Panel, changes the sandboxing applied to the caller by removing its constraint to that specific protected folder. As the sandboxing isn’t controlled by or reflected in Privacy & Security settings, that allows TCC, in Files & Folders, to continue showing access restrictions that aren’t applied because the sandbox isn’t applied.

Conclusion

Access restrictions shown in Privacy & Security settings, specifically those to protected locations in Files & Folders, aren’t an accurate or trustworthy reflection of those that are actually applied. It’s possible for an app to have unrestricted access to one or more protected folders while its listing in Files & Folders shows it being blocked from access, or for it to have no entry at all in that list.

Is this likely to occur?

Most apps that want access to protected folders like Documents appear to seek that during their initialisation, and before any user interaction that could result in intent overriding the need for consent. However, many users report that apps appear to have access to Documents but aren’t listed in Files & Folders, suggesting that at some time that sequence of events does occur.

To be effectively exploited this would need careful sequencing, and for the user to select the protected folder in an Open and Save Panel, so drawing attention to the manoeuvre.

Most concerning is the apparent permanence of the access granted, requiring an arcane command in Terminal and a restart in order to reset the app’s privacy settings. It’s hard to believe that this was intended to trap the user into surrendering control over access to protected locations. But it can do.

I’m very grateful to Richard for drawing my attention to this.

Privacy: Files & Folders or Full Disk Access?

By: hoakley
8 April 2026 at 14:30

Alongside RunningBoard, TCC and privacy protection are among the greatest contributors to the Unified log, although they’ve been a little less loquacious more recently. This article sheds light on what they do when an app tries to access the contents of a protected folder. Log extracts were obtained from Insent 1.1 running in macOS 26.4 on a Mac mini M4 Pro, and concentrate on what happens when Insent tries to ‘open by consent’, first listing the contents of ~/Documents, then picking a text file at random and displaying some of its contents.

Relevant entries from the log are given in the Appendix at the end of this article.

Accessing ~/Documents by consent

When the Open by consent button is clicked, Insent first tries to obtain a listing of the Documents folder. That request is considered to be sandboxed, so the sandbox service requests authorisation to proceed from TCC.

When it receives that request from sandboxd, TCC first checks whether the requesting app has been granted Full Disk Access, formally the kTCCServiceSystemPolicyAllFiles service. An early step in that sequence is to establish the attribution chain, so TCC can check the correct process, in this case Insent’s executable code.

A second check is then started, to determine whether the requesting app has been granted the more restricted service of kTCCServiceSystemPolicyDocumentsFolder. Those requests are followed by many validation checks on the Insent executable.

The simplest outcome is that Insent has kTCCServiceSystemPolicyAllFiles, in which case access is granted to the sandbox, and the Documents folder is listed as requested.

If Insent doesn’t have that, TCC considers kTCCServiceSystemPolicyDocumentsFolder:

  • if that has already been granted, TCC tells the sandbox to grant access;
  • if that has neither been granted nor denied, TCC displays the dialog requesting user consent, and acts accordingly;
  • if that had been granted but has been disabled (denied) in Privacy & Security, TCC denies access without seeking any consent.

This demonstrates an important difference in the behaviour of Full Disk Access (kTCCServiceSystemPolicyAllFiles) and locations protected by Files & Folders (here kTCCServiceSystemPolicyDocumentsFolder). Disabling Full Disk Access doesn’t deny access, it just doesn’t enable it. Disabling a specific protected location in Files & Folders will deny that app access to that location.

If you want to return an app’s Files & Folders settings to the default, so you will be prompted to consent for access, you therefore need to remove that app’s entry from Files & Folders, and might also need to log out and back in, or restart, to ensure that’s put into effect.

These are summarised in the diagram above. For the sake of simplicity, access granted under SystemPolicyAllFiles isn’t shown separately, but merged with that under SystemPolicyDocumentsFolder.

Interactions between Full Disk Access and individual access in Files & Folders can appear complicated, even random at times, but are actually the result of logical decisions. They are also reflected faithfully in Privacy & Security settings. For example:

  • Remove all settings for Insent from both Files & Folders and Full Disk Access.
  • Open Insent, click on Open by consent, and agree to add the app to Files & Folders with Documents access.
  • Quit Insent, and disable its Documents access in Files & Folders but don’t remove it. Then add Insent to the Full Disk Access list.
  • Confirm that Open by consent still functions correctly, because its Full Disk Access setting overrides Files & Folders, as shown in the latter settings. Quit Insent.
  • Remove Insent from the Full Disk Access list, and it will be listed in Files & Folders with access to Documents disabled once again.

Summary

  • If the app at the head of the attribution chain has been given Full Disk Access, access to list and read files will be given.
  • If not, then location-specific access in Files & Folders will be applied.
  • If there’s no setting for that app and location, the user is asked for consent.
  • If that app has already been given consent for that location, access to list and read files will be given.
  • If that app has consent denied or disabled, access to list and read files will be denied.
  • None of these controls apply to access by user intent in a File Open dialog, or to writing files.

Open and Save Panel access

As I have made clear, when a user expresses their intent to open a file by selecting it using the Open and Save Panel, that doesn’t trigger the same system of access rules. However, the request is still considered by TCC, this time using the Attribution Chain to examine the app rather than that panel service.

When looking briefly at log entries for that sequence, I noticed something odd: instead of the TCC access request being made for a location-related policy such as SystemPolicyDocumentsFolder, it’s recorded as kTCCServiceScreenCapture. Whether that’s a bug or intended behaviour, the request was authorised, and access proceeded.

The first time I saw that, I was so surprised that I repeated the test using Insent to confirm that I wasn’t misunderstanding the log entries. Exactly the same happened a second time, despite Insent having nothing whatsoever to do with making screenshots.

Previously

Consent, intent and privacy
Privacy: protected folders

Appendix: Log Extracts

Each entry is prefaced with the clock time in seconds.

Request, dialog and approval:

In this case, Insent hadn’t made any prior request to access the Documents folder in that session, so had no entry in Privacy & Security settings. When its access dialog was displayed, consent was granted, allowing access to proceed. As with other extracts, this starts with the event marking the button click in Insent.

1.204592 Insent sendAction:
1.205160 Insent: trying to list files in ~/Documents
1.205828 sandboxd request approval
1.205919 sandboxd tcc_send_request_authorization() IPC
1.206291 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd.system: request: msgID=440.94, function=TCCAccessRequest, service=kTCCServiceSystemPolicyAllFiles,
1.207414 com.apple.TCC AttributionChain: accessing={TCCDProcess: identifier=co.eclecticlight.Insent, pid=2232, auid=501, euid=501, binary_path=/Applications/Insent.app/Contents/MacOS/Insent}, requesting={TCCDProcess: identifier=com.apple.sandboxd, pid=440, auid=0, euid=0, binary_path=/usr/libexec/sandboxd},
1.235893 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd: request: msgID=440.95, function=TCCAccessRequest, service=kTCCServiceSystemPolicyDocumentsFolder,

[TCC then makes various checks on Insent]
1.261591 com.apple.TCC AUTHREQ_PROMPTING: msgID=440.95, service=kTCCServiceSystemPolicyDocumentsFolder, subject=Sub:{co.eclecticlight.Insent}Resp:{TCCDProcess: identifier=co.eclecticlight.Insent, pid=2232, auid=501, euid=501, binary_path=/Applications/Insent.app/Contents/MacOS/Insent},
1.265001 com.apple.TCC No usage string found (key:NSDocumentsFolderUsageDescription) for client[2232] in bundle:[private]
1.265006 com.apple.TCC display_prompt: called for [private] for service kTCCServiceSystemPolicyDocumentsFolder

[The access dialog is displayed, and consent given]
3.798770 com.apple.sandbox kTCCServiceSystemPolicyDocumentsFolder granted by TCC for Insent
3.802225 com.apple.chrono appAuth:co.eclecticlight.Insent] tcc authorization(s) changed
3.809558 Insent: trying to look in ~/Documents for text files
3.809691 Insent: trying to read from: /Users/hoakley/Documents/asHelp.text
3.842101 Insent: read from: /Users/hoakley/Documents/asHelp.text

Request after approval:

In this case, Insent had already been granted consent to access the Documents folder, as recorded in Privacy & Security settings.

0.911529 Insent sendAction:
0.912220 Insent: trying to list files in ~/Documents
0.913379 sandboxd request approval
0.913482 sandboxd tcc_send_request_authorization() IPC
0.913953 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd.system: request: msgID=440.100, function=TCCAccessRequest, service=kTCCServiceSystemPolicyAllFiles,
0.915394 com.apple.TCC AttributionChain: accessing={TCCDProcess: identifier=co.eclecticlight.Insent, pid=2255, auid=501, euid=501, binary_path=/Applications/Insent.app/Contents/MacOS/Insent}, requesting={TCCDProcess: identifier=com.apple.sandboxd, pid=440, auid=0, euid=0, binary_path=/usr/libexec/sandboxd},
0.949736 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd: request: msgID=440.101, function=TCCAccessRequest, service=kTCCServiceSystemPolicyDocumentsFolder,

[TCC then makes various checks on Insent]
0.970955 com.apple.TCC AUTHREQ_RESULT: msgID=440.101, authValue=2, authReason=2, authVersion=1, desired_auth=0, error=(null),
0.971072 com.apple.sandbox kTCCServiceSystemPolicyDocumentsFolder granted by TCC for Insent
0.973350 Insent: trying to look in ~/Documents for text files
0.973532 Insent: trying to read from: /Users/hoakley/Documents/piklisting.text
1.035508 Insent: read from: /Users/hoakley/Documents/piklisting.text

Request denied:

In this case, Insent had previously been given access to the Documents folder, but that was then disabled.

1.033344 Insent sendAction:
1.034069 Insent: trying to list files in ~/Documents
1.035189 sandboxd request approval
1.035299 sandboxd tcc_send_request_authorization() IPC
1.035820 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd.system: request: msgID=440.108, function=TCCAccessRequest, service=kTCCServiceSystemPolicyAllFiles,
1.037404 com.apple.TCC AttributionChain: accessing={TCCDProcess: identifier=co.eclecticlight.Insent, pid=2303, auid=501, euid=501, binary_path=/Applications/Insent.app/Contents/MacOS/Insent}, requesting={TCCDProcess: identifier=com.apple.sandboxd, pid=440, auid=0, euid=0, binary_path=/usr/libexec/sandboxd},
1.071652 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd: request: msgID=440.109, function=TCCAccessRequest, service=kTCCServiceSystemPolicyDocumentsFolder,

[TCC then makes various checks on Insent]
1.093533 com.apple.TCC AUTHREQ_RESULT: msgID=440.109, authValue=0, authReason=4, authVersion=1, desired_auth=0, error=(null),
1.093669 com.apple.sandbox kTCCServiceSystemPolicyDocumentsFolder denied by TCC for Insent
1.094007 Insent: couldn't get contents of ~/Documents

Open and Save Panel Oddity:

In this case, the Open from folder button in Insent was used to select the Documents folder, ready to allow the app access by intent. This extract shows what happened after the button in the Open and Save Panel was clicked.

8.800555 com.apple.appkit.xpc.openAndSavePanelService trackMouse send action on mouseUp
8.802062 com.apple.appkit.xpc.openAndSavePanelService tcc_send_request_authorization() IPC
8.802140 com.apple.TCC SEND: 0/7 synchronous to com.apple.tccd.system: request: msgID=2259.2, function=TCCAccessRequest, service=kTCCServiceScreenCapture,
8.802469 com.apple.TCC AttributionChain: responsible={TCCDProcess: identifier=co.eclecticlight.Insent, pid=2255, auid=501, euid=501, responsible_path=/Applications/Insent.app/Contents/MacOS/Insent, binary_path=/Applications/Insent.app/Contents/MacOS/Insent}, requesting={TCCDProcess: identifier=com.apple.appkit.xpc.openAndSavePanelService, pid=2259, auid=501, euid=501, binary_path=/System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/com.apple.appkit.xpc.openAndSavePanelService.xpc/Contents/MacOS/com.apple.appkit.xpc.openAndSavePanelService},
8.809596 com.apple.TCC Handling access request to kTCCServiceScreenCapture, from Sub:{co.eclecticlight.Insent}Resp:{TCCDProcess: identifier=co.eclecticlight.Insent, pid=2255, auid=501, euid=501, responsible_path=/Applications/Insent.app/Contents/MacOS/Insent, binary_path=/Applications/Insent.app/Contents/MacOS/Insent}, ReqResult(Auth Right: Unknown (None), promptType: 1,DB Action:None, UpdateVerifierData)
8.809609 com.apple.TCC AUTHREQ_RESULT: msgID=2259.2, authValue=1, authReason=5, authVersion=1, desired_auth=0, error=(null),

Privacy: protected folders

By: hoakley
7 April 2026 at 14:30

On Sunday I introduced some of the principles involved in the protection of folders, to preserve your privacy, and provided a small test app, Insent. This article follows on with additional concepts, details, and a new version of Insent that writes diagnostic information to the log. This article refers to privacy protection as implemented in macOS Tahoe 26.4.

The macOS privacy system is more formally known as Transparency, Consent and Control (TCC), and is built around its manager tccd, working alongside the security system and the sandbox service sandboxd. The last might surprise those who thought that sandboxing was only required for apps provided in the App Store, but this sandbox is different.

How it works

When an app makes certain types of request of the file system, including those seeking a list of files (e.g. with FileManager’s contentsOfDirectory() method), or opening a file for read access, that request is passed to sandboxd for approval. That in turn queries TCC to discover whether that app should be authorised for that access. Depending on the path to be accessed, TCC checks in its database of policy approvals, runs various safety checks on the app’s signature and other properties, then tells sandboxd whether the request should be approved or denied.

As I revealed in the previous article, TCC’s controls over folders only apply to reading their directory and file contents. If an app wants to write a file to one of those protected locations, privacy restrictions don’t apply, only conventional Posix permissions. This is easily verified using the Save buttons on the left side of Insent’s window, which can write test files wherever you as a user have sufficient privileges. This is an important distinction, and a consequence of TCC’s purposes.

Reading directory listings and file contents is also different when it’s a user intent. This is most characteristically performed using the File Open dialog, where only the user gets to see the lists of files, and has complete control over which file is opened. This is handled by a separate XPC process, the Open and Save Panel Service, which has automatic approval. The same mechanism applies to the Open Recent command, drag-and-drop, double-clicking the document, and using the Finder’s Open command.

Attribution

The Open and Save Panel Service is also an example of another fundamental concept in macOS privacy protection, that of the attribution chain.

This is often encountered when considering how privacy protection can be applied to command tools that lack a GUI that could support TCC’s dialogs. Ultimately, each process has a GUI app responsible for it, and it’s that app which TCC uses as the front-end. In the case of most command tools that are run from Terminal, the attribution chain ends in Terminal.

If you want your command tools to have Full Disk Access, you thus add the Terminal app to the list in Privacy & Security settings. The disadvantage of this design is that it gives Full Disk Access to all command tools run in Terminal’s shell, and could get you into trouble if one turns out to be flawed or malicious. This can be exploited by ClickFix attackers, which trick you into pasting malicious commands into Terminal, and is a good reason for not leaving Terminal with Full Disk Access any longer than is necessary.

Daemons or services, whose name normally ends in d, are seldom run from Terminal, and when they require Full Disk Access can be added as individual binaries, although they can’t normally be given access to individual Files & Folders.

Protected folders

I’ve been unable to discover a comprehensive and up-to-date official list of protected folders and locations, but the following appear to be those most frequently used:

  • ~/Documents
  • ~/Downloads
  • ~/Desktop
  • removable volumes
  • iCloud Drive
  • third-party cloud storage
  • network volumes
  • Time Machine backups.

The first three are by far the most common in most Macs, with Removable Volumes close behind. Others are more dependent on your hardware configuration, for example whether you use network shares or third-party cloud services.

Purpose

The overriding principle in privacy protection is to minimise access given to potentially sensitive files.

Apps that are intended to access files anywhere or everywhere, such as backup apps and those used to detect duplicate files, should normally be given Full Disk Access, as should be advised in their documentation. That requires you to put trust in them not to abuse their privilege, and in their supplier to ensure they aren’t the victim of a supply-chain attack. If you have any doubts whatsoever, don’t install that app, and certainly don’t give it Full Disk Access.

Other apps should only be given access to Files & Folders when you’re invited to give your consent in one of TCC’s dialogs, and then only if you consider the app has a sufficiently good reason to be given that access, and can be trusted not to abuse it. All this should be explained in the app’s documentation, and better apps cover it in their onboarding sequence.

The Files & Folders list is different from Full Disk Access. You pick and choose which apps to give Full Disk Access to, and can leave an app listed there but with access disabled, to ensure it will remain blocked. TCC decides which apps are offered for inclusion in the Files & Folders list on the strength of their making a request of the file system that triggers sandboxd to ask TCC if it has been approved for such access. You can’t add apps of your choice, but you can disable an access that has already been granted, and remove that app from the list.

In the next article I’ll show what happens in the log when sandboxd and TCC are in action. This has been made much easier in a new version of Insent which writes detailed entries in the log. If you want to study those, Insent 1.1 is now available from here: insent11
For those who don’t want to dive that deep, version 1.0 is the same in all other respects, and is available from here: insent10

Who called git, and how Claude was caught red-handed

By: hoakley
17 March 2026 at 15:30

When the same unusual dialog appears twice within a few days for two different people, you begin to suspect a pattern. This article explores a rabbit hole that involves git, the log and the fickleness of AI.

On 8 March, Guy wondered whether an XProtect update earlier this month could have been responsible for a dialog reading The “git” command requires the following command line developer tools. Would you like to install the tools now? As the request seemed legitimate but its cause remained unknown, we mulled a couple of possible culprits, and he went off to investigate.

Five days later, after he had installed the update to SilentKnight 2.13, Greg emailed me and asked whether that might be responsible for exactly the same request appearing on his Mac. This time, Greg had consulted Claude, which asked him to obtain a log extract using the pasted command
log show --start "2026-03-13 07:07:00" --end "2026-03-13 07:10:00" --style compact --info | grep -E "14207|spawn|exec|git|python|ruby|make"

Armed with that extract, Claude suggested that SilentKight had been the trigger for that dialog.

I reassured Greg that, while SilentKnight does rely on some command tools, it only uses those bundled with macOS, and never calls git even when it’s feeling bored. While I was confident that my app couldn’t have been responsible, I wondered if its reliance on making connections to databases in my Github might somehow be confounding this.

While I knew Claude was wrong over its attribution, the log extract it had obtained proved to be conclusive. Within a few minutes of looking through the entries, I had found the first recording the request for command line tools:
30.212 git Command Line Tools installation request from '[private]' (PID 14205), parent process '[private]' (parent PID 14161)
30.212 git Command Line Tools installation request from '[private]' (PID 14206), parent process '[private]' (parent PID 14161)

As ever, the log chose to censor the most important information in those entries, but it’s dumb enough to provide that information elsewhere. All I had to do was look back to discover what had the process ID of 14161, as its parent. Less than 6 seconds earlier is:
24.868 launchd [pid/14161 [Claude]:] uncorking exec source upfront

Just to be sure, I found matching entries for SilentKnight and the system_profiler tool it called after the attempt to run git:
30.153 launchd [pid/14137 [SilentKnight]:] uncorking exec source upfront
30.336 launchd [pid/14139 [system_profiler]:] uncorking exec source upfront

There was one small mystery remaining, though: why did Claude’s log show command also look for process ID 14207? That was the PID of the installondemand process that caused the dialog to be displayed:
30.215 launchd [gui/502/com.apple.dt.CommandLineTools.installondemand [14207]:] xpcproxy spawned with pid 14207

Following its previous denial, when Claude was confronted with my reading of the log, it accepted that its desktop app had triggered this dialog. Its explanation, though, isn’t convincing:
“the Claude desktop app calls git at launch — likely for one of a few mundane reasons like checking for updates, querying version information, or probing the environment. It’s not malicious, but it’s poorly considered behavior for an app that can’t assume developer tools are present on every Mac.”

In fact, it was Guy who had probably found the real reason, that the Claude app has Github as one of its four external connectors. However, that shouldn’t give it cause to try running the git command, resulting in this completely inappropriate request.

Conclusions

  • Claude might know how to use the log show command, but it still can’t understand the contents of the Unified log.
  • If you’re ever prompted to install developer command tools to enable git to be run, suspect Claude.
  • What a fickle and ever-changing thing is an AI.*

I’m very grateful to Greg and Guy for providing the information about this curious problem.

* This is based on a well-known English translation of a line from Virgil’s Aeneid, Book 4: “Varium et mutabile semper femina”, “what a fickle and ever-changing thing is a woman”. While all of us should dispute that, there’s abundant evidence that it’s true of Claude and other AI.

How long does the log keep entries?

By: hoakley
12 March 2026 at 15:30

One of the most contentious questions arising from yesterday’s critical examination of ChatGPT’s recommendations, is how long does the Unified log keep entries before they’re purged? ChatGPT seemed confident that some at least can be retained for more than a month, even as long as a year. Can they?

Traditional text logs are removed after a fixed period of time. One popular method is to archive the past day’s log in the early hours of each morning, as part of routine housekeeping. Those daily archives are then kept for several days before being deleted during housekeeping. That’s far too simple and restrictive for the Mac’s Unified log.

Apple’s logs, in macOS and all its devices, are stored in proprietary tracev3 files, sorted into three folders:

  • Persist, containing the bulk of log entries, retained to keep their total size to about 525 MB in about 50-55 files;
  • Special, including fault and error categories, whose entries are slowly purged over time until none remain in the oldest log files, so have a variable total size and number.
  • Signpost, used for performance measurements, which also undergo slow purging until they vanish.

One simple way to estimate the period for which log entries are retained is to find the date of creation of the oldest log file in each of those folders. On a Mac mini M4 Pro run largely during the daytime, those dates were

  • Persist, earliest date of creation 7 March 2026 at 16:54
  • Special, 9 February 2026 at 19:41
  • Signpost, 3 March 2026 at 16:41

when checked on 10 March. Those indicate a full log record is available for the previous 3 days, followed by a steady decline with age to the oldest entry 31 days ago. That compares with statistical data available in my app Logistician going back as far as 14 January, although all entries between then and 9 February have now been removed and lost.

Retrieving old log entries

The real test of how many log entries have been retained is to try to retrieve them. Although the oldest Special log file was created on 9 February, the oldest log entry I could retrieve was the start of the boot process on 11 February, in Special log files returning a total of over 44,000 entries for that day. However, no further log entries could be found after those until the morning of 24 February, a gap of over ten days.

This chart shows the numbers of log entries that could be found and read at intervals over previous days. Where a total of 500,000 is shown, that means over 500,000 for that 24 hour period. I checked these using two different methods of access, using the OSLog API in LogUI, and via the log show command in Ulbow. In all cases, log show returned slightly fewer than OSLog.

It’s clear that with only 3 days of full Persist log files, very few entries have been retained from earlier than 7 days ago, and beyond that retention numbers are erratic.

Over the period prior to the oldest Persist file, when entries could only be coming from Special log files, those included both regular and boundary types, and categories were diverse, including fault, error, notice and info, and weren’t confined to the first two of those categories. Most subsystems were represented, but very few entries were made by the kernel. There is thus no obvious pattern to the longer retention of entries in Special files.

Ephemeral entries

Log entries are initially written to memory, before logd writes most of them to permanent storage in tracev3 log files on disk.

mul102LogdFlow

The first substantial purging of entries thus occurs when logd decides which are ephemeral and won’t be retained on disk. This can be seen by following the number of entries in a short period of high activity in the log, over time, and is shown in the chart below for a sample period of 3 seconds.

When fetched from the log within a minute of the entries being written, a total of 22,783 entries were recovered. Five minutes later there were only 82% of those remaining. Attrition of entries then continued more slowly, leaving 80% after 8 hours. Analysis suggests that over this period in which there were about 6,100 log entries per second written to disk, approximately 1,700 log entries per second were only kept in memory and never written to disk. That suggests about 22% were ephemeral, a proportion that’s likely to vary according to the origin and nature of log entries.

Summary

  • A fifth of log entries are likely to be ephemeral, and lost from the log within the first minutes after they’re written.
  • Most retained log entries are written in Persist logs, where tracev3 files are removed by age to keep their total size to just over 500 MB. Those should preserve the bulk of log entries for hours or days after they’re written.
  • Entries stored in Special log files may be retained for significantly longer, here up to a maximum of 29 days. Although those may contain fault and error categories, retention doesn’t follow an obvious pattern, making their period of retention impossible to predict.
  • In practice, the period in which a fairly complete log record can be expected is that applied to Persist files, which varies according to the rate of writing log entries. In most cases now that’s unlikely to be longer than 5 days, and could be less than 12 hours.
  • You can’t draw conclusions from the apparent absence of certain log entries from the log prior to the earliest entries in Persist log files, as it’s likely that those entries will have been removed.
  • Expecting to retrieve log entries from earlier than 5 days ago is almost certain to fail.

Why does AI tell you to use Terminal so much?

By: hoakley
11 March 2026 at 15:30

There’s a striking difference between troubleshooting recommendations made by AI and those of humans. If you’ve tried using AI to help solve a problem with your Mac, you’ll have seen how heavily it relies on commands typed into Terminal. Look through advice given by humans, though, and you’ll see they rely more on apps with GUI interfaces. Rather than sending you straight to fsck_apfs, for instance, most humans will prefer to direct you to Disk Utility and its First Aid feature.

This is because most popular AI like ChatGPT, Claude and Grok is based on LLMs, Large Language Models, built on tokens for words. The great majority of humans using Macs work primarily in its GUI, using apps rather than Terminal commands. Verbalising the use of GUI apps is relatively difficult, and with the popularity of YouTube rather than written blogs, is becoming a dying art.

Command tools are all very well, but in this context they have disadvantages, among them being:

  • Few understand the commands used, and AI seldom explains those provided unless explicitly asked to do so. This results in the human learning little other than a long list of incomprehensible commands, and acquiring neither understanding nor insight.
  • Commands often lack the safeguards normally built into in apps, so can more readily cause damage or mislead.
  • Commands can readily generate overwhelmingly large output, even when piped to a file for later browsing.
  • Pasting commands into Terminal has become a favourite way to trick the unsuspecting into installing malware.

Even for an advanced user, confident assertions made by an AI can mislead. Here’s an example taken from ChatGPT’s advice on potential detections of malicious software. For this I have set ChatGPT’s output in italics, together with its commands as code. It’s worth noting that each command was explicitly given for the bash command shell, although in macOS Catalina (in 2019) Terminal changed to use zsh rather than bash as its default.

ChatGPT starts this exchange with a teaser that few could resist:
If you want, I can also show you how to tell in 10 seconds whether a Mac actually has malware despite these logs (there are 3 very specific indicators in Console).

Vague predicate

Here’s the most reliable way to see if macOS has ever detected malware on your Mac using Apple’s internal security logs.
1. Check the XProtect malware history
Open Terminal and run:

log show --predicate 'subsystem == "com.apple.XProtectFramework"' --last 30d

This log show command doesn’t access “Apple’s internal security logs”, which don’t exist, but the Unified log. Nor does the recommendation use Console to access the log, as promised. The predicate given is too non-specific to be useful for the stated purpose, and the time period of 30 days is absurdly long and doesn’t match the claimed period either.

On my Mac with the longest log records, its oldest Special tracev3 log file was created on 9 Feb 2026, and now has only 43 KB left from its original size of 11,298 KB, and the next oldest from 10 Feb has 34 KB left from 11,148 KB. On an older Intel Mac, the oldest creation date of a Special log file was 6 March, just 4 days previously, not 30.

When run on the first of those on 10 March, with longer log records, that log show command returns two Fault entries from 11 Feb, and more complete records from Special logs starting on 2 March, but no full log records until 6 March.

The predicate used is too general to select useful entries and is overwhelming, as it returns a total of 1,505 log entries for that command.

Log entries a year old

2. Specifically check for remediation events
To filter just real detections:

log show --predicate 'eventMessage CONTAINS "remediat"' --last 365d
If nothing prints, no malware has been removed in the last year.

ChatGPT here defines “real detections” as those for which remediation was attempted. I know of no evidence from research to support that assumption. Given the limitations in retrieving log entries from 30 days noted above, it seems absurd to assume that any log entries will be retained from over 360 days ago.

It’s malware only if blocked

3. Check Gatekeeper malware blocks
Run:

--predicate 'process == "syspolicyd" AND eventMessage CONTAINS "malware"' --last 365d

ChatGPT has here redefined its original claim to limit it to malware that was blocked by Gatekeeper, and once again assumes it can retrieve log entries from over 360 days ago.

No verification

4. Verify XProtect definitions are current
Run:

system_profiler SPInstallHistoryDataType | grep -i xprotect
You should see recent updates like:
XProtectPlistConfigData
XProtectPayloads
Apple updates these silently in the background.

This is one of its most curious recommendations, as system_profiler is the command line interface to System Information, a familiar and far more accessible app. What that command does is look for the case-insensitive string “xprotect” in the Installations list. Unfortunately, it proves useless, as all you’ll see is a long list containing those lines, without any dates of installation or version numbers. On my older Mac, piping the output to a file writes those two words on 6,528 lines without any other information about those updates.

I know of two ways to determine whether XProtect and XProtect Remediator data are current, one being SilentKnight and the other Skint, both freely available from this site. You could also perhaps construct your own script to check the catalogue on Apple’s software update server against the versions installed on your Mac, and there may well be others. But ChatGPT’s command simply doesn’t do what it claims.

How not to verify system security

Finally, ChatGPT makes another tempting offer:
If you want, I can also show you one macOS command that lists every XProtect Remediator module currently installed (there are about 20–30 of them and most people don’t realize they exist). It’s a good way to verify the system security stack is intact.

This is yet another unnecessary command. To see the scanning modules in XProtect Remediator, all you need do is look inside its bundle at /Library/Apple/System/Library/CoreServices/XProtect.app. The MacOS folder there should currently contain exactly 25 scanning modules, plus the XProtect executable itself. How listing those can possibly verify anything about the “system security stack” and whether it’s “intact” escapes me.

Conclusions

  • Of the five recommended procedures, all were Terminal commands, despite two of them being readily performed in the GUI. AI has an unhealthy preference for using command tools even when an action is more accessible in the GUI.
  • None of the five recommended procedures accomplished what was claimed, and the fourth to “verify XProtect definitions are current” was comically incorrect.
  • Using AI to troubleshoot Mac problems is neither instructive nor does it build understanding.
  • AI is training the unsuspecting to blindly copy and paste Terminal commands, which puts them at risk of being exploited by malicious software.

Previously

Claude diagnoses the log

又一次重建 Hexo Blog

By: Battle Le
22 October 2025 at 00:00

昨天想更新 blog,没想到就是下午迁移出了问题,然后又是花了一个晚上排查问题。后来才发现好简单……所说是无用的调试,还是记录一下,免得以后又遇到。

掉进坑(无用调试)

执行 git pull origin main 后出错

1
2
3
4
5
6
luckye@Lucky-Mac-mini lucky-blog % git pull origin main

ERROR: Repository not found.
[fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

提示远程仓库不存在,问了 ChatGPT 说是SSH 密钥的问题,生成公钥和私钥重新添加后也不起作用。

ls -al 后有 .git 文件,确认下命令行有没有走代理流量

1
curl -I www.google.com

返回正常,再看看能不能连接到 GitHub

1
ssh -T -p 443 git@ssh.github.com

输入 yes 也是正常。看看 git branch 在哪个分支上,是 main。

在 GitHub-Code-Local-SSH 直接复制项目名,执行

1
git remote set-url origin git@github.com:xxx/xxx.github.io.git

输入后没反应是正确的,接着

1
2
3
git pull
返回
fatal: couldn't find remote ref main

再确认分支有没有错

1
2
3
git branch -a
返回
* main

接着查看当前 Git 仓库的本地配置文件内容的命令

1
2
3
4
5
6
7
8
9
10
11
12
cat .git/config
返回
[core]
repositoryformatversion = 0
filemode = true
bare = false
[remote "origin"]
url = git@github.com:username/repo.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
remote = origin
merge = refs/heads/main

接着查看当前 HEAD(最新提交)的一些详细信息

1
2
3
4
5
6
7
git show --summary
返回
commit 5d0ca94755d1dbe39f5be0983 (HEAD -> main, origin/main, origin/HEAD)
Author: xxx <xxxgmail.com>
Date
Fri Oct 17 23:47:06 2025 +0800
"update"

这些看着都没问题那就只好重新 clone 一下了。重新 push 创建了新的 main 分支

1
git push -u origin main

我把 Default 设置为 main,把 master 删除。重新 clone 一下 main 分支。更改默认分支后进行 clone。

移动再克隆

第一步直接 mv

1
mv ~/本地文稿/lucky-blog ~/本地文稿/lucky-blog-bak

bak 就是 backup 的缩写

第二步 git clone

1
git clone git@github.com:xxx/xxx.github.io.git ~/xxx-blog

重新安装 Hexo

1
ls /opt/homebrew

奇了怪了,Homebrew 也不生效,其实并不是没了,而是当前 PATH 没指向 /opt/homebrew/bin。干脆就全部安装下吧。要开启 Qutumult X 开启 SS 服务器功能,不然没有代理无法下载。安装 Homebrew

1
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

要执行下面三条命令才能安装

1
2
3
4
5
echo >> /Users/lucky/.zprofile

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/lucky/.zprofile

eval "$(/opt/homebrew/bin/brew shellenv)"

clone 之后文件夹重命名,重新安装 Hexo

1
2
3
brew install node
brew install git
npm install -g hexo-cli

水落石出

就在我以为重装能成功之后结果还是不行,越弄越烂,最后还是麻烦余光帮我排查,在私人仓库添加一个 collaborator,他上去一看就发现问题所在。

仓库和 Cloudflare 所关联的根本不是同一个半年前我已经迁移到 Cloudfare,新建了一个 repo,全然忘记老的仓库不再使用,所以牛头不对马嘴😅

Clone 正确仓库

那接下来就简单了,重新备份(昨晚已经备份过,跳过),然后再 clone。类似于重启大法,对正确的这个仓库没有进行过操作,都不用安装 Homebrew,Hexo,所以异常的快速简单。

使用 GitHub 图形界面

改动了啥一目了然

这一次,终于抛弃那些繁琐的命令,本来就搞不懂。下载 GitHub 图形界面,登陆 GitHub 账号,然后设置 git config 关联的邮箱,因为 git 标准里要求必须有邮箱(和登录的 GitHub 账号没有关系),可以选择匿名邮箱账号,为了不出幺蛾子用自己邮箱登陆,选中仓库(别再选错),一键 Clone,选择保存路径。

然后只有两步,Commit to main 然后 Push origin,搞定。想看本地渲染的还是

1
2
cd ~/blog 
hexo s

如果提示没有项目依赖就装一个,都不用全局安装

1
npm install

在老的 MacBook Pro 上也同样部署了,比以前方便太多,另一台下次更改前先 Push origin (⌘ + P) 一下就好。

大功告成!感谢余光,FriendsA 帮我排查了这么久时间🙏

疑难点

之前排查的过程中,老 repo 的线上分支 Default 是 master,但是也有 main,以为是项目的 mastermain 不同导致的错误。(这两个其实只是名字区别,只是最近主流都用 main 了)

  • branch 指的是 Hexo push 的远程分支

  • 如果 Git 仓库默认分支是 main,_config.yml 必须写 main,否则 Hexo 会往 master 推送(即使你的本地 default 是 main)

  • 只修改 _config.yml 并没有提交,这个修改是本地未保存的 Git 改动。Hexo 会用最新的文件夹去 push,但 Git 依旧会检测到本地未提交改动

  • 因此,如果想 Hexo push 到 main,最好先把 _config.yml 的修改提交或保存,避免被 Git 阻止。

在 _config.yml 中修改

deploy:
type: ‘git’
repo: git@github.com:luckylele666/luckylele666.github.io.git
branch: master

master 修改为 main

如果是在本地部署可以这样设置,但是我现在的构建方式不是这样了。

原理

传统 Hexo 部署

以前常用的流程:Hexo 本地 → hexo g(生成静态文件) → hexo d(推送到远程服务器/仓库)

  • _config.yml 的 deploy配置是关键,指定仓库和分支
  • Hexo 自己负责生成 public/ 并把它推送到 GitHub 或其他远程
  • 必须在本地先生成,再上传

不足:

  • 每次修改都要本地生成
  • 本地要安装完整 Hexo 环境(Node、主题、插件)才能生成

Cloudflare Pages 部署

我现在的模式是:GitHub 仓库(纯代码,私人仓库,更加隐私) → Cloudflare Pages(自动构建 & 发布)

特点:

  1. 自动化构建:Cloudflare 会在 push 到 main 分支时自动执行 Hexo generate,生成 public/ 并直接发布到站点
  2. 不依赖 Hexo deploy,不用再在本地运行 hexo d,也不需要在 _config.yml 里配置分支
  3. 纯 Git 流程:只需要用 git add → commit → push 管理版本,Cloudflare 会负责构建和部署(用了 GitHub 图形管理界面甚至都不用 Git 命令

为什么不用 hexo g,hexo d

因为 hexo d 其实做了两件事:

  1. 生成静态文件(hexo g)
  2. 把生成的 public/ 推送到指定远程分支(hexo d)

而 Cloudflare 已经代替了第 2 步:

  • Cloudflare 会在云端执行构建(等同于 hexo g)
  • 自动把生成结果发布到你的 Pages 网站

所以本地运行 hexo g hexo d 反而是多余的,甚至可能把 Git 历史搞乱(尤其是 _deploy_git/ 里嵌套 Git 仓库的情况)。


用下来个人感觉在代码方面,免费版之间,ChatGPT>Grok>Gemini,不要太过于相信 AI 的答案,现阶段感觉还是不如人脑。

💡注释

  • ~ 是 用户>xxx 的别名
  • cd 是 change directory(切换目录) 的缩写
  • ~ 表示 当前用户的主目录(home 目录)
  • /blog 是主目录下的一个子文件夹

一个 INJT 的工作室里有什么?

By: Steven
27 April 2025 at 20:40

这期视频,是我的工作室 Roomtour。

第一部分,介绍了空间内的四个大件;

第二部分,向观众交待近半年的情况;

第三部分,聊了正在开展的艺术项目。

视频的最后,给设计师观众们留下了一个问题。

🎥 观看视频:https://www.bilibili.com/video/BV1XEjAzREam/

🎥 观看视频:https://youtu.be/ZieOsQ1dFeI

误入 Autumn leaves 音乐现场的观众(C调)vlog.74

By: Steven
24 February 2025 at 20:07

【曲目】Autumn leaves

【场地】一方音乐·深圳龙岗

【鼓手】阿吉

【吉他】筱烨、秋夏

【键盘】菜菜

【贝斯】苏志斌

点击这里跳转到 BiliBli 观看:https://www.bilibili.com/video/BV1ZYAReSEv4

点击这里跳转到 Youtube 观看:https://youtu.be/W5ytb1LRvhM

在 github 架设 hugo blog(纯浏览器操作)

By: fivestone
11 November 2024 at 21:12

我其实对 Hugo 不熟,不知道这算不算重新发明了一遍轮子。但我搜索「如何在 github 上,用 hugo 架设自己的 blog?」时,搜到的教程,都需要用户在自己的电脑上,安装运行各种 git 和 hugo 的相关命令,感觉对新手并不友好。所以,我试着写了一个流程,让新人完全只需要在网页浏览器上操作,就能快速生成自己的 blog 网站。

所有操作都在 Github 这个项目上进行:
https://github.com/fivestone/hugo-papermod-beginning

这个项目本质上,就是搭了一个空白的 hugo 网站,让用户 fork 到自己的账户下,设置一下就能直接使用。对功能和界面有什么额外要求的话,请自行学习 hugo 的进阶教程。——然后你们就不是需要用这个项目的新人啦~

  • 本项目基于 hugo 博客引擎,和流行的 PaperMod 主题
  • 在 github 上建立的 blog,在墙内是不能直接访问的,需注意

1. 创建 github 账号

首先,注册自己的 github 账号,过程略。注册过程中,你设置的账户名 username,通常就是最终的网站地址 username.github.io,当然以后也可以把自己的域名映射到上面。

2. 架设自己的 blog 项目

注意,这一步,有两种方法

  • 第一种方法:你建一个全新的项目,下载我提供的 .zip 文件,解压后,再手动上传到你的项目。和第二种相比,稍微繁琐一点。但还是希望大家,有条件的话,使用这种方法。
  • 第二种方法,把我的这个项目,fork 到你的项目。这种方法对新人更简便,完全不需要在本地操作文件,只用手机或 pad 就可以完成。但这种 fork 在一起的项目,在进行自动发布 blog 的操作时,是共享同一个操作额度的。如果 fork 的人数非常多,未来可能会被 Github 限制。——要达到这种规模,大概要几千人同时用吧……所以也不需要很在意。
2.1. 第一种方法

注册并登入账号后,新建自己的项目(Repository)。

项目的名称,决定了最终 blog 的网址。假设你的 github 用户名为 username

  • 如果把项目命名为 username.github.io ,则最终的网站地址为
    https://username.github.io/
  • 如果把项目设置成其它名字,如 new-name,则最终的网站地址为
    https://username.github.io/new-name

确认项目为 Public。其它设置都不需要更改,点击绿色按钮创建。

创建项目后,点击「上传已有的文件」

我的 github 项目,下载已经设置好的 hugo 文件包,在本地解压缩 .zip 文件。然后,把里面的所有文件,拖拽上传到你的项目里。

等到 80 多个文件都被上传后,别忘了点击页面底部的 Commit changes 提交。

2.2. 第二种方法

注册并登入账号后,进入项目:
https://github.com/fivestone/hugo-papermod-beginning
点击 Fork,将这个模板复制到你自己的账号下。

和第一种方法一样,这里需要设置你自己的项目名称,假设你的 github 用户名为 username

  • 如果把项目命名为 username.github.io ,则最终的网站地址为
    https://username.github.io/
  • 如果把项目设置成其它名字,如 new-name,则最终的网站地址为
    https://username.github.io/new-name

然后点击 Create fork 创建项目。


3. 配置自动发布 blog

创建新项目后,进入项目的 Settings – Pages 页面,把 Build and deployment – Source,改为 GitHub Actions。

把 Source 从 Deploy from a branch,改为 GitHub Actions 后,进入上方的 Actions 页面。

初次进入 Actions 页面后,会显示 Github 预设的各种配置方案,通过搜索框找到 hugo,然后点击 hugo 方案中的 Configure

系统会自动生成配置文件,不需要做任何改动,点击绿色的 Commit changes 提交。

此时自动发布的 action / workflow 就已经开始运行了,大约 1~2 分钟后,就可以在
https://username.github.io 看到 blog 最初的页面了。

以后,每次对项目里文章或配置文件的更改,都会触发这个 action / workflow,重新生成一遍网站。可以在 Actions 页面,查看 workflow 每次运行的情况。


4. 更改网站基本信息

在 Code 页面,点击编辑 config.yml 页面,把一些预设的网站信息,改成你自己的信息。

对新人来说,需要在 config.yml 文件里更改的,大概有以下几项:

baseURL: https://username.github.io/ # 改成你自己的网址
title: 网站名称
params:
  author: somebody # 作者的署名

  homeInfoParams:
    Title: 网站标题,只显示在首页上
    Content: >
      显示在首页标题下方的一些文字。</br>
      支持一些简单的 html 和 markdown。

更改后,点击绿色的 Commit Changes… 在弹出的页面中,再一次点击绿色的 Commit Changes,保存文件后 1~2 分钟,就可以在 blog 页面上,看到更改后的内容了。


5. 添加、管理文章

所有的 blog 文章,都在 content / posts 目录中。在 Code 页面,进入 content / posts 目录。点击右上角,创建新文件。

所有的文章,均为 .md 结尾的 markdown 文件。文件名对应着这篇文章的网址,譬如,post-20241111.md 文章链接,就是
https://username.github.io/posts/post-20241111/

在文件的开头,如图所示,写入用 — 隔开的,文章的标题和发布日期。

---
title: "新文章的标题"
date: "2024-11-11"
---
然后开始写正文,markdown 格式。

同样,点击绿色的 Commit changes… 保存提交。1~2 分钟后,就可以在 blog 页面上看到新文章了。

content / posts 目录里的所有文件,都可以随意地新增、删除、修改、重命名文件。对应着 blog 文章的增删改、和改变 url 链接。

文章内嵌的图片,建议放在 static 目录下,然后在文章中用 markdown 格式引用。譬如 static / aa.jpg 文件,相应地在 markdown 文件中插入的代码为:

![](https://username.github.io/aa.jpg)

有经验的用户,也可以使用其它更有效的组织方式。


6. 其它注意事项

  • 生成的 blog 对应的 rss 订阅地址为
https://username.github.io/index.xml
  • 如果是用第二种方法,直接 fork 的项目,以后在这个 blog 项目里,会一直看到,图片里这样的消息,提示要把你对项目的更改,反馈给原本的我的项目。——不用理会就是了。

输出是一种排泄

By: Steven
20 May 2024 at 21:13

在不同的平台上时不常的都能看到一些内容创作者他们会有疑问,说我的东西明明很有深度,准备得也很充分,制作也很用心,但是为什么没有获得很好的流量,或者其他的回报?这种时候要么就是真的有疑问,要么就是想通过这种疑问的方式,来表达对于这种流量的不满或者鄙视。

每次看到他们说这种话的时候,我就会代入到自己。我也有很多内容是花了很多心思很认真做的,但就是没有什么人看,没有什么人听。前几年确实会有疑惑,但现在我很坦诚地接受自己就是不擅长做那种大众流量欢迎的内容。

这里并没有鄙视大众流量的意思,我是真的发自内心的不懂,哈哈哈哈哈~

因为我做内容 99% 的动机,都只是为了把脑袋里的东西腾出来,它只是我的一个思考过程的外化。有人获得共鸣和启发,那就最好,没有那也无所谓。因此我确实没有真的花过心思在研究怎么样制作大家都喜欢的那种类型的内容,因为我也确实没有发自真心地想把自媒体作为自己的一条所谓职业赛道来看待。

因此,没有获得那样的流量,是很正常,也应该的。

分类法

By: fivestone
10 April 2024 at 21:16

把 blog 的文章分类整理一下。

这项任务已经拖延了超过十年,早就没意义了。blog 页面上,已经很多年没有放置分类列表。曾经企图把所有文章归入 uncategorized,然后用 tag 来做分类,——幸好没有,不然又是个半途而废的坑。

还是先把分类的框架搭出来吧。即使有了框架,从前的旧帖子,也还没有妥善归置到各个分类里,继续拖着吧。


yy – /yy

也就是「意淫」,初代互联网口头语之一。某种意义上,整个 blog 的所有文章,都是在 yy,所以从这个网站初建,这就是分类之一。内容偏向于各种奇怪的,未必和情欲相关的幻想。也经常觉得 yy 这个词渐渐不合时宜、甚至有些男性油腻,想换个更高大上的(譬如 P.Bourdieu 的 illusio…);但,还是先这么放着吧。

日子流 – /current

流水账。早年 blog 大兴的时候,一大群人的文章风格,都是今天吃了什么玩了什么买了什么。我也想学着这么接地气一些,但最终还是没写太多。网址的英文名,出自卡佛的《水流》。

nowhere man – /nowhere

旅行相关,或者日常生活中偏向旅行气质的片段。出处是 Beatles。

norwegian wood – /wood

情感相关。出处是村上春树当然也是 Beatles。

不正经的 – /funny

纯搞笑段子。

偶知道 – /seriously

一些比较认真的思考吧。「偶知道」既是偶然知道,也是我知道,——(偶 = 我)仍然是上古网络用语,尴尬到脚抠地。

他们 – /ille

偏向于对他人的描述,有网络引用的,也有实际访谈的。ille 是第三人称自指。关于他者的描述,终归还是要映照自身。

无政府主义审美 – /aesthetic

最初是时政方面的吐槽。后来也包括从无政府主义视角,对同温层内部的一些不同的观感。然而并不会努力地,专注于用这个 blog 向人普及反贼言论,所以最终还是轻轻地立足于「审美」两个字,说些只是看着不爽的东西。

love me do – /tech

和人文情感无关;一些在各种兴趣领域的技术攻略:攀岩、射箭、外语、IT……

拍拍 – /photography

作为童年爱好,这个 blog 曾经把「摄影」作为一个二层分类的顶端,下面包括很多细微的分类:拍的照片、心得、理论讨论……甚至还有过一个摄影 blog,后来停掉了,也没有合并过来。这边还多多少少留了些,就先堆在这里。——所以心中还是对此有爱的吧。要知道,连 IT 类原创都没资格独占一个分类,而是胡乱塞进 /tech /fyi /misc 里面……

FYI – /fyi

For Your Information,感觉会对很多人有用的资源。和 /tech 类似,但兴趣方面的含量就低了很多,只是当作工具来整理,也未必是原创。

misc – /misc

杂项。

把日常阅读的网页,用 RSS 推荐给好友

By: fivestone
8 March 2024 at 22:10

虽然大家写 blog 的频率都没那么勤了,但是,RSS 还是有其它可以玩的方式的!

很多人都有用各种 read it later、或者书签类工具,把有意思的网页保存下来。在这些工具里,可以通过某些手法,把一些想要分享的网页,生成 rss。其他好友订阅这个 rss 地址,就可以自动刷新,看到你推荐的文章啦!

下面介绍一些,常见的书签网站,生成 rss 的方式。但首先——

  • 这些生成的 rss 地址里,大多都内嵌着网站的验证码,容易泄密,也冗长而不简洁。强烈建议:得到 rss 后,先用 Feedburner 之类的网站,转成新的 rss,再分享出来,可以去掉原先网址里的隐私信息。
  • 很多网站,并没有专门用来 share 的分类,只能通过曲线手段,把已经 archive 或者 star 的类别分享出来。这可能会影响你原本的使用习惯。
  • 一些网站生成的 rss,并没有全文,甚至只有标题和链接地址。没关系,能看到大家的推荐,就已经很好了,自己点开就可以啦。
  • 大多数 rss 订阅工具里,也都有发送给 read it later 的功能,可以辗转着,把自己订阅的文章分享给他人。

我的 RSS 分享地址是:

https://feed.fivest.one/readings
或者
https://feeds.feedburner.com/fivestone/readings

有兴趣和我分享的,欢迎留言或私信交换!!


Instapaper 免费版

感觉 Instapaper 生成 RSS 的功能是最好用的,可以把特定的文件夹设为公开,直接得到它的 rss,形如:

https://instapaper.com/folder/1234567/rss/123456/Vciysdfsd7mod9B
  • 在左边栏创建新的 Folder,存放想要分享的文章;
  • 进入这个 Folder,在页面上方选择 Edit,设置成 Public;
  • 点击页面右上角的下拉菜单,选择 Download;
  • 下载为 RSS Feed,就得到 RSS 地址了。

Pocket 免费版

好像 Pocket 的免费用户,内容都只能是公开的(无语…),只要知道了用户名,就可以通过 RSS 查看全部的内容(所以生成的 rss 需要转录才安全)。而且不能自定义分类,只有默认的:

https://getpocket.com/users/USERNAME/feed/all
https://getpocket.com/users/USERNAME/feed/unread
https://getpocket.com/users/USERNAME/feed/read

最后一条 …/read 会返回所有 Archived 了的文章,可以勉强用它作为分类的手段。

Readwise

这个只有收费版,我就不去试了。有它家的用户,可以帮忙把生成 rss 的方法分享一下?

Wallabag

我在用 Wallabag,可以自建,也有收费的服务可用。生成的 rss 是全文输出,效果很好。在 Config – Feed 里,生成一个 token,然后点开任何一个 tag,点击列表上方的 rss 图标,就可以得到这个 tag 的 rss 订阅(生成的地址里带着统一的 token,所以需要转录才安全):

https://wallabag.your.domain/feed/USERNAME/asdfghjkl/tags/t:share

博客实现 RSS 订阅能力全记录

By: 李瑞东
11 November 2022 at 21:17

我的个人网站 LRD.IM 从 2018 年元旦发布至今,已经持续维护 4 年了。从最开始根据一个网站模板替换图文,到现在全面的「自主研发」,这是我最骄傲的一款作品。接下来要开始尝试将我的博客内容输出成 RSS 源。

这篇博客不谈设计。写一点自己对互联网的初印象,将博客做成 RSS 源的原因,以及使用 RSSHub 将自己网站生成订阅源的过程。

吹吹水:我的互联网回忆录

对早期互联网的印象

家里 2005 年配置了台电脑,依稀记得那会儿互联网的潮流正好是从门户网站转换到「社会性网络」。

Discuz!、贴吧、QQ空间、开心网等等,都是 Web 2.0 的代表作,我「当年」也有高度参与到这些生态里面。那时候的互联网鼓励人们创造内容,强调互动和内容本身。而不像现在基于所谓的「算法」一直在投喂内容,网站上充斥着营销号、广告、对立、(甚至审查🤫)…

我记得以前网络上的内容是挺有趣的,因为都是自发的内容,感觉很真实。而现在在网上看到「有趣」的内容,却总感觉像是某个 MCN 机构生产出来的,所有内容都有目的,一直在包装、孵化,指向最后的变现…

所以正好我这位在 Web 2.0 时代背景下成长的网民,正好也有掌握了一些专业知识,于是乎就捣鼓出属于我的个人网站 LRD.IM,以及目前为止积累了 40 多篇的设计博客。一方面是想通过这些来积累自己的专业知识,另一方面是更想在互联网上留下自己的(且属于自己)的一些痕迹。

对 RSS 的执念

以前在 WordPress 搭建的博客、新闻资讯等网站总会有一个 RSS 订阅渠道,最初还没有了解过是什么意思,只是记住了有这个很不起眼的橙色的彩虹条纹的图标。

直到在大学了解到了一些信息获取来源方式和分类之后,才真正了解到 RSS 这个东西。很神奇的是它将内容进行重新格式化输出,将内容和从页面中分离出来,供读者在自己喜欢的第三方阅读器里接收新内容并阅读。

我还是挺认同这个概念的,即使它是 20 年前的产物。

分离原本的网页,意味着读者可以根据自己喜好在第三方阅读器上进行阅读,甚至自己捣鼓一个阅读器,而并非局限在原本网页管理者的设计中。

而第三方阅读器通常都会有新内容通知、已读未读标记、分类、标签等功能,这意味着读者能够拥有自己的一套信息获取方式,而不需要受到算法的介入,并能及时获得新内容的推送。

正好由于今年我的设计博客还上了不少公众号、周报的推荐,我察觉到拥有一个自己的内容推送服务迫在眉睫,而 RSS 订阅、邮件订阅都能满足这个需求,正好我就先将 RSS 订阅服务做起来先。

综上所述,我认同 RSS 的中立、纯粹、无算法介入,以及需要获取一个推送功能。所以,这时的我作为互联网内容生产者,是时候为自己的博客搭建一个 RSS 服务了!

实打实:将自己的网站生成 RSS 订阅源

预期

首先阐述下我的预期效果:

  • 抓取到 Blog 页面里的所有博客,并能检测到内容变动(包括增删改);
  • 将抓取的内容生成为 RSS 要求的格式,比如 XML;
  • 更新内容时,在第三方阅读器中确保至少的时效性(不会延迟太久)和内容准确度(顺序不会错乱);
  • 订阅链接用回自己的域名。

尝试一:第三方生成服务

于是乎我首先也试了几个做法,第一个是寄托于第三方的 RSS 生成服务。比如 Feed43FeedburnerRSS.app。当时我是期望这些第三方服务能够满足上述的预期效果,自动抓取我发布的新博客生成为 RSS 文件。它们确实也做到了,但会各自有一些硬伤。

  • Feed43:更新快,准确。但是免费版里生成的 Feed 里面会带有它们品牌的宣传,且国内访问速度一般;
  • Feedburner:更新速度一般,准确。但是被墙了,国内无法正常访问。
  • RSS.app:更新快,准确。但是只能抓取前几条内容,想要保留所有内容需付费升级账号。是否被墙倒是没试过。

试了一遍论坛/讨论组内大伙儿推荐的 RSS 生成服务提供商,没有完美地达到我的期望,每个都是差一点,只能靠自己了。

尝试二:手动制作静态文件

眼见外部服务不好使,于是乎我跑去看了看 RSS 的语法规范,尝试用最笨的方法:按照语法自己手动编写一份 XML 文档出来,给到读者去订阅。

大费周章按 RSS 语法规范写完了 XML,传了两份用作测试,一份传在自己的阿里云轻应用服务器上,另一份传到了阿里云 OSS 里。之后用第三方阅读器订阅 RSS 链接。

结果在阅读器里看到顺序错乱,时间异常,更新非常迟缓。刚开始我还以为这个笨方法能行得通,只是做起来比较麻烦,没想到仍然有这么多缺点。

最后一试:用 RSSHub 将自己网站生成为 RSS 源

了解 RSSHub
前两种方法试过都不能满足我的要求之后,我实在找不到一个好的思路或方向去实现,唯有在 V2EX 上发了个帖子请教下其他人。虽然帖子只有两个人回复,但足够启发我去解决问题了。

一楼回复建议我给 RSSHub 提个申请,让其他人写个规则来抓取我的网站,然后合并到 RSSHub 项目里,用该链接作为 RSS 的订阅链接。

后面我去了解了下 RSSHub,原来这是一个开源的 RSS 订阅源生成器,编写好规则(项目内称为脚本)后就能将内容按照 RSS 的语法生成一份订阅源,之后都可以用生成出来的链接在第三方阅读器上订阅和浏览。同时可以部署在自己的服务器里面,也能直接用 RSSHub 项目内别人预先编写好的规则,两者的效果是一样的。

粗浅了解下 RSSHub 的能力,以及也看了用该服务生成出来的订阅链接,功能上是能解决我的问题,但是时效性、准确度这些得自己部署完才能知道。

二楼回复认为静态的 XML 文件作为订阅源,会存在着不受我控制的缓存机制。于是乎我更坚定地认为应该尝试使用 RSSHub 的服务,毕竟这是动态生成,不是一个憨憨的静态文件。

安装 RSSHub
登录到服务器,由于我用的网站在阿里云轻服务器上搭建的,所以直接在网页里就能远程登录,其他服务器也能 ssh 登录后依次输入指令安装并运行 RSSHub。

git clone https://github.com/DIYgod/RSSHub.git
cd RSSHub
npm install
npm start

成功安装并运行后,在浏览器访问 1200 端口应该能看到如下页面。

回到终端,设置 RSSHub 服务常驻(断开 ssh 链接后仍然保持服务);以及开机自启。

# 设置常驻
npm install pm2 -g
pm2 start lib/index.js
# 设置开机自启
pm2 save
pm2 startup

这时可以访问几个 RSSHub 项目自带的路由,探索下其他有趣的 RSS 源。然后开始编写自己的脚本路由。

编写脚本路由
这一部分我的思路是参考文档的指引,并且在 RSSHub 项目内找到已有的脚本路由,找一份与自己网页结构类似的脚本,照葫芦画瓢捣鼓一份出来。

按文档的说法,/lib/router.js 里面记载了所有路由,即指明通过域名访问而指向的脚本。我先在里面创建一个路由,让其链接到之后创建的脚本。

# 添加路由
router.get('/feed', lazyloadRouteHandler('./routes/lrdim/blogs'));

其中 /feed 意思是我希望通过域名/feed 能够访问到我的 RSS 源,即 lrd.im/feed。后面的 ./routes/lrdim/blogs 意思是用前面的链接访问时,是链接到 /routes/lrdim/blogs.js 这个文件,用里面的规则生成 RSS 源。

然后到 /lib/routes 里面创建 lrdim 这个文件夹,并在里面创建 blog.js 这个文件,我们的抓取规则要写在里面。

由于我的网站是静态的 HTML 页面,所以我按照文档里的第二种方法,按照元素的标签和样式来抓取里面的数据。并且当时有参考了一个网页结构同样很简单的 RSSHub 内置源:十年之约。具体做法不在这详细说明了,主要按文档规范走就没啥问题,cheerio 语法也很直观容易理解。

保存后过几分钟,已经能在 lrd.im:1200/feed 中访问生成的 RSS 源了。此时需检查下名称、描述、标题、摘要、日期等有没有问题。

注意:日期必须按照格式编写,不能出现非法内容。否则这条 item 不会出现在结果中。我是写成了 YYYY-MM-DD。

调整渲染模版
由于刚刚通过设置 RSSHub 脚本获取到的数据,会经过 rss.art 模版处理后再成为 RSS 订阅源,所以我们需要打开 /lib/views/rss.art 对渲染模版作出相应的调整,比如预设 <webMaster> 不符合预期,调整为我自己的邮箱。

设置代理
至此,我的 RSS 订阅源已经生成完毕,内容、格式等符合要求,剩下的只有域名还不大对劲。

截至到上面的步骤,我的 RSS 订阅源扔人家需要通过端口来访问:lrd.im:1200/feed。这个肯定是不能作为最终产物的,谁会把端口直接暴露出来,太丢人了。于是乎需要配置最后一步:设置代理。

我的服务器里安装了 nginx,打开 nginx/conf/nginx.conf 后配置代理,将 lrd.im/feed 指向 1200 端口的页面。

location /feed {
proxy_pass http://127.0.0.1:1200;
}

此时测试 lrd.im/feed,已经能正常访问经 RSSHub 生成的订阅源。

验收
拿订阅链接去各主流阅读器中试验,尝试搜索、添加此链接,并尝试增删改被抓取的网页内容,检查到确实能够及时更新,且不会信息错乱。

大功告成!奉上我的设计博客正式的 RSS 订阅链接:https://lrd.im/feed

将该链接复制到 RSS 阅读器上就能够及时获取我的最新设计博客了。阅读器的话看个人喜好,目前我觉得 InoreaderReeder 的体验都不错。

做多啲:在网站中曝光 RSS 订阅功能

费了这么大周章捣鼓的新功能,起码在我的网站里多多曝光才是。所以我顺手做了三件事。

支持 RSSHub Radar

RSSHub 有一个浏览器插件叫 RSSHub Radar,用于探测网站上提供的 RSS,让读者能在浏览器的插件位置直接就能订阅,而不必在网页上费劲去找 RSS 订阅按钮。

支持该功能也不怎么复杂,我在所有页面的 <head> 处都添加了一条订阅地址,就能够被 RSSHub Radar 识别到。

博客页新功能提示

既然是我的博客内容的 RSS 源,那理所当然地应该在 lrd.im/blog.html 里添加一个稍微醒目一点的 Banner,提示到当前已经支持 RSS 啦!

此处参考了 Instagram 和 Apple 的样式,高亮若干秒之后开始减弱对比,使其融入到页面中。用了 CSS 的 keyframe 来做。

博客详情页功能组

从 Google Analytics 处跟踪到的数据,挺多流量是来自直接的博客详情页,而不是先从列表页跳转到详情页。所以也为了增加在详情页的曝光,我在「作者信息」一行右侧新添加了几个按钮,分别是:复制文章链接、RSS 订阅、联系小东。

原本「复制文章链接」这个功能我是做成响应式设计,只在移动端尺寸下才能看到,但还是根据 GA 数据反馈,造访我的博客的流量中有至少 75% 是来自桌面端,所以我将这个功能开放了。

「RSS 订阅」功能点击后能直接跳转到 lrd.im/feed,后续的订阅操作懂得都懂。每篇文章都提供这个入口,极大提高曝光量。

「联系小东」的功能是点击后出现我的微信二维码。我的设计博客通常会输出我的观点和看法,而我的网站里面又没有评论的功能,所以我捣鼓了一个微信二维码上去,读者如果有东西想和我交流就能直接加我好友一起交流。

这些功能没做成悬停在左右两侧,原因是我不太想在读者阅读时有其他干扰项。

哦对了,还顺便 Close 了一个,也是目前唯一一个 Issue。

总结

给博客生成 RSS 订阅源这事虽然一直惦记了有大半年,但实际开始到最终呈现,历时一周左右,都是用下班时间和周末探索的。

又到了给自己挖坑的时间:后面关于博客订阅这块,我会做的几件事:

  • 想办法将自己的 RSS 源链接提交到 RSSHub 项目下的博客分类
  • 研究主流的 RSS 阅读器抓取文章首图的规则。现在抓取的首图并非每次都符合我的预期,可能本身我的博客详情页构造需要作些许调整;
  • 探索开拓邮箱订阅功能的必要性。目前 Medium 能够用邮箱订阅我的最新博客动态,在想是否需要用到 Revue竹白之类的自己捣鼓一个邮件订阅服务,内嵌到个人网站里面去。顾虑是担心这种平台的文本编辑器功能是否够完善,以及和 Medium 功能重复了。

完成了自己的一项执念,如释重负,舒坦开朗。但心里仍然藏了另一项执念,我惦记了有至少一两年了,仍待推进…

参考文档

Hosting Ghost Blog with Docker on NixOS

By: Orchestr
20 August 2023 at 22:44
Hosting Ghost Blog with Docker on NixOS

As previously mentioned, I have successfully deployed NixOS on my Oracle ARM machine. You can find the original post here:

How to Install NixOS on Oracle ARM machine
The steps I undertook to install NixOS on an Oracle ARM machine.
Hosting Ghost Blog with Docker on NixOSDigital ImmigrantsOrchestr
Hosting Ghost Blog with Docker on NixOS

In the past, my blog was hosted on Tencent Cloud using Typecho. Unfortunately, due to unforeseen circumstances, I lost ownership of that machine along with all my previous posts. Consequently, I took a hiatus from blogging, remaining in a state of silence for a few years. However, I now realize the importance of reviving my blog before lethargy engulfs me.

After conducting extensive research and considering various platforms such as Ghost, WordPress, Typecho ,Hugo and some other platforms, I finally settled on Ghost. Its remarkable speed, plethora of customized themes, aesthetically pleasing web user interface, and integrated membership system influenced my decision.

Check out all the cool stuff Ghost has to offer on their website below:

Ghost: The Creator Economy Platform
The world’s most popular modern publishing platform for creating a new media platform. Used by Apple, SkyNews, Buffer, Kickstarter, and thousands more.
Hosting Ghost Blog with Docker on NixOSGhost - The Professional Publishing Platform
Hosting Ghost Blog with Docker on NixOS

Due to the absence of Ghost in the NixOS packages, and the cumbersome nature of adapting it into a NixOS service, Docker has emerged as an excellent solution for hosting Ghost. Here, I have provided a comprehensive breakdown of the steps I followed to set up a blog using Ghost with Docker on NixOS. This can be modified to use on other platforms.

Step 0: Enable Docker on NixOS

Enabling Docker(Podman) on NixOS is a straightforward process, requiring modification of just one configuration file. I personally prefer using the vim editor, but feel free to use your preferred tool such as nano, emacs, or VS Code.

The initial step involves logging into the machine, particularly if it is being used as a server.

ssh ${username}@${server IP}

Then, we can start to modify the configuration file:

sudo vim /etc/nixos/configuration.ni

There are two ways of adding Docker to the NixOS system: for all users:

environment.systemPackages = with pkgs; [
  docker
];

And for one user only:

users.users.${username}.packages = with pkgs; [
  docker
];

You can choose either way based on your needs. The next step is to enable the Docker service.

virtualisation.docker.enable = true;
virtualisation.oci-containers.backend = "docker";

Note that we're using oci-containers to control Dockers. If you have chosen to install Podman, remember to modify it accordingly. Some may question why we're not using docker-compose; this is a simple answer – we embrace the capabilities of NixOS, and that suffices.

Last, remember to create a directory for docker to use. Here's my example:

mkdir ~/.docker

Step 1: Set up Docker Network

Using the Docker CLI command docker network will indeed create the network, but it may not be the optimal approach. Since we're operating within the context of NixOS, we can add it as a service. Add the following code snippet to your configuration.nix file, ensuring to customize the name according to your requirements. In my case, I'm utilizing npm as an example since I'm employing nginx-proxy-manager as my Nginx reverse proxy service.

systemd.services.init-docker-ghost-network-and-files = {
  description = "Create the network npm for nginx proxy manager using reverse proxy.";
  after = [ "network.target" ];
  wantedBy = [ "multi-user.target" ];

  serviceConfig.Type = "oneshot";
  script =
    let dockercli = "${config.virtualisation.docker.package}/bin/docker";
    in ''
      # Put a true at the end to prevent getting non-zero return code, which will
      # crash the whole service.
      check=$(${dockercli} network ls | grep "npm" || true)
      if [ -z "$check" ]; then
        ${dockercli} network create npm
      else
        echo "npm already exists in docker"
      fi
    '';
};

Step 2: Set up Mysql for Ghost

We will now proceed with crafting Docker configurations. The initial step involves creating an external directory for MySQL to store its data, ensuring that we can modify MySQL without accessing the Docker environment directly. At present, this MySQL database is exclusively intended for Ghost; however, you have the freedom to tailor it according to your specific requirements.

mkdir ~/.docker/ghost-blog/mysql -p

Please add the following snippet to your configuration file as well:

virtualisation.oci-containers.containers."ghost-db" = {
  image = "mysql:latest";
  volumes = [ "/home/hua/.docker/ghost-blog/msql:/var/lib/mysql" ];
  environment = {
    MYSQL_ROOT_PASSWORD = "your_mysql_root_password";
    MYSQL_USER = "ghost";
    MYSQL_PASSWORD = "ghostdbpass";
    MYSQL_DATABASE = "ghostdb";
  };
  extraOptions = [ "--network=npm" ];
};

Please note that Ghost no longer supports SQLite and MariaDB as its database options.

Step 3: Set up Ghost Docker

Finally, It's time for Ghost.

Basic Set up Configuarion

Following the previous instructions, we will proceed to create the content folder:

mkdir ~/.docker/ghost-blog/content

Now, let's move on to configuring Ghost:

virtualisation.oci-containers.containers."ghost-blog" = {
  image = "ghost:latest";
  volumes =
    [ "/home/hua/.docker/ghost-blog/content:/var/lib/ghost/content" ];
  dependsOn = [ "ghost-db" ];
  ports = [ 3001:3001 ];
  environment = {
    NODE_ENV = "develop";
    url = "http://${server IP}:3001";
    database__client = "mysql";
    database__connection__host = "ghost-db";
    database__connection__user = "ghost";
    database__connection__password = "ghostdbpass";
    database__connection__database = "ghostdb";
  };
  extraOptions = [ "--network=npm" ];
};

Within this section, we configure the port mapping, environment variables, and volume mapping. Please note that you should customize the MySQL configurations in accordance with your specific setup in the final step.

Mail Server Set Up

Taking Gmail as an example, please note that you can modify this configuration according to your specific needs.

virtualisation.oci-containers.containers."ghost-blog".environment = {
  mail__transport = "SMTP";
  mail__option_service = "Google";
  mail__options__auth__user = "username@gmail.com";
  mail__options__auth__pass = "your google app password";
  mail__options__host = "smtp.gmail.com";
  mail__options__port = "587";
  mail__options__secure = "false";
  mail__from = "username@gmail.com";
  tls__rejectUnauthorized = "true";
}

Please remember that the Google app password mentioned here is different from your actual Google account password. You can generate a Google app password by following the steps outlined in the Sign in with app passwords guide.

By configuring these settings, visitors will be able to sign up and leave comments on our website.

More Custom Options

Please refer to the instructions provided on the Ghost website at the following link:

Configuration - Adapt your publication to suit your needs
Find out how to configure your Ghost publication or override Ghost’s default behaviour with robust config options, including mail, storage, scheduling and more!
Hosting Ghost Blog with Docker on NixOSGhost - The Professional Publishing Platform
Hosting Ghost Blog with Docker on NixOS

Step 4: Set up Nginx Reverse Proxy

There are numerous articles available on the internet that explain how to set up Nginx as a system service or utilize nginx-proxy-manager as a Docker service. For the purpose of this example, I will demonstrate the Docker service approach. Remember to create the necessary folders as well.

virtualisation.oci-containers.containers."nginx-proxy-manager" = {
  image = "jc21/nginx-proxy-manager:latest";
  dependsOn = [ "ghost-blog" "chatgpt-next-web" ];
  volumes = [
    "/home/hua/.docker/nginx-proxy-manager/data:/data",
    "/home/hua/.docker/nginx-proxy-manager/letsencrypt:/etc/letsencrypt"
  ];
  ports = [ "80:80", "443:443", "81:81" ];
  extraOptions = [ "--network=npm" ];
};

Step 5: Rebuild System

sudo nixos-rebuild switch`

Step 6: Start to Use

After rebuilding the system, you can proceed to open the web pages for both Ghost and nginx-proxy-manager.

For information and usage details about Ghost, please visit:

Ghost: The Creator Economy Platform
The world’s most popular modern publishing platform for creating a new media platform. Used by Apple, SkyNews, Buffer, Kickstarter, and thousands more.
Hosting Ghost Blog with Docker on NixOSGhost - The Professional Publishing Platform
Hosting Ghost Blog with Docker on NixOS

To learn more about nginx-proxy-manager, please visit:

Nginx Proxy Manager
Docker container and built in Web Application for managing Nginx proxy hosts with a simple, powerful interface, providing free SSL support via Let’s Encrypt
Hosting Ghost Blog with Docker on NixOS
Hosting Ghost Blog with Docker on NixOS

Please note that once you have set up the nginx reverse proxy for Ghost, it's necessary to modify the Docker configuration for Ghost as follows:

virtualisation.oci-containers.containers."ghost-blog".environment = {
  NODE_ENV = "production";
  url = "https://your-website-address";
}

Please replace your-website-address with the actual address of your website. After making this modification, rebuild the system again.

In conclusion, if you have any further questions, please feel free to leave a comment without hesitation.

苟日新

By: fivestone
5 September 2023 at 07:41

突然被人跑来问,是怎么做到写博客坚持这么久的,而且可以持续输出?

(荣幸地,拿起话筒:)啊,我不觉得我这个样子,叫做「持续输出」啦。早就连每月一更都不能保证了,而且那些技术相关的帖子,在我心里都不能算是「更新博客」的,用这些凑数也为我自己所不齿……

但我看到这个问题时,首先想到的,一个很重要的因素:大概是因为,这个站就一直在这儿吧~ 我的技术能力,不需要花什么额外的精力,就能让这个 blog 一直存活下去。于是,想写东西的时候,这里始终有个地方,可以让我写。

——也有很多时期,是完全写不下去的,长时期没法去面对、去反刍自己的生活;然而也没必要因此而关站,就让 blog 存活在那里,终归是个表述的出口。大概是因为,我也是希望,自己能够从那些「无法整理自己」的状态中,渐渐走出来,回复到可以写东西的状态吧。所以站点的持续存在,满重要的,因为确实能感觉到,想写点什么的时候,如果没有这么个站,又或者需要自己重新架一个,可能也就不写了……


这种「随时可以在站点写东西」的状态,也影响着对 blog 平台的选择(怎么又拐到技术贴去了?好吧,之前也一直想吐槽这方面,就顺带提一下)。这些年一直有 〖wordpress vs 各种静态博客〗哪个更好的争论。双方确实各有利弊。总体来说,静态博客最大的优点就是……省钱,可以薅 github、vercel 之类托管网站的羊毛。但另一方面,静态博客每次发布、或者修改一篇文章的过程,其实满折腾的。通常情况下,它需要

  • 一台固定的电脑,安装静态博客编译程序,并且从这台电脑发布到 github 的专门权限。而不是随便打开一台电脑或手机,从浏览器就能编辑发文;
  • 每次发文时的一系列专门操作。

我不乏看到有人,好久没有更新,突然想写一篇文章时,忘了怎么操作,翻出攻略来重温一遍;甚至忘了连接 github 的 ssh-key……可能别人觉得这样的折腾无所谓,或者自我管理优秀的话,不会出现这种情况。但我个人觉得,这是会在主观上,影响发文章的状态的。所以,随便在任何地方任何电脑上都能直观地发文,感觉还是蛮重要的。

好像也是可以通过一系列操作,实现用浏览器某个网站上编辑文章,然后自动编译发布到托管网站的。我没有仔细去关注。但是,如果把 blog 的生命周期,放到 5~10 年这个尺度上,那么这些网站之间的复杂依赖关系,很大程度上是不靠谱的。譬如我已经看到好几个静态 blog 的外挂评论系统,不知为什么不工作了……总之,相比之下,我可能更宁愿去使用那些免费带广告的 blog 平台。

我对写 blog 的新人的推荐,一直是——

  • 如果有技术能力、也有服务器的话,自建 wordpress;
  • 或者找人蹭一个。如果我们比较熟,你可以去买个域名,把 blog 挂在我的服务器上。这并不是很大的负担。(ps,个人 wordpress 小站,是可以不必安装开销很大的 mysql 数据库的);
  • 如果上面两条都不行,那么,我优先推荐去注册现成的 wordpress.com 或者 blogspot.com,目前看起来,长期靠谱的只有这两家了。虽然免费版界面不好看、还有广告,但长期写着应该没问题的;
  • 当然,我不会给乐于尝试静态博客的人泼冷水。但我会根据你的技术能力和气质,暗戳戳地担心:
    • 你能坚持写多久;
    • 你写出来的,会不会很多都是关于你怎么建站的经历和心得……

转一张,对于熟悉这十几年来 blog 平台变迁的人,应该会很搞笑:用不同工具写 blog 的人,(写 blog 文章)vs(写关于怎么配置 blog 的文章)的对比。右下角那些术语,都是在各个年代,需要各种不同程度的折腾的,静态 blog 方案:gatsby、org mode、jekyll、hugo、git workflow……


ps,两个月前,用这段代码方案,把我在 twitter 的所有 po 文,都导入到了自建的 mastodon 里。Twitter 那边,应该会随着 Elon Musk 的各种不靠谱折腾,渐渐放弃掉了吧。而每条推文的字数限制,从 twitter 的 140 字,变成 mastodon 的 500 字后,很多几百字的感受,要不要专门写到 blog 这边来,就比从前,更让人犹豫。具体怎么处理,我还没想好。

[Plog] 西藏游 Day 6: 念青唐古拉观景台

By: Justin
13 September 2023 at 22:51

念青唐古拉山脉中的“念青”在藏语中意为“次于”,此山脉规模仅次于唐古拉山脉。 念青唐古拉山脉是雅鲁藏布江与怒江分水岭, 也是高原上寒冷气候带与温暖(凉)气候带的分界线。 主峰念青唐古拉峰海拔 7162米 。

The post [Plog] 西藏游 Day 6: 念青唐古拉观景台 appeared first on Justin写字的地方.

[Plog] 西藏游 Day 5: 大昭寺 & 八廓街

By: Justin
3 September 2023 at 14:17

为期七天的行程到第五天其实就已经快近尾声了,心中也渐渐酝酿出不舍的情绪。比起初到拉萨时的高反和前几天高原风光带来的视觉上的冲击,第五天的行程给我们带来的更多是心灵和文化上的洗礼。

The post [Plog] 西藏游 Day 5: 大昭寺 & 八廓街 appeared first on Justin写字的地方.

❌
❌