Post not yet marked as solved
Not exactly. I have the patches for both, but I'm looking for comments on the use of dnsextd (hopefully from someone in the networking group) on its viability with recent versions of BIND. Also their thoughts on the overall scheme, like relying on the TSIG implementation in macOS for secure record updates. FB10279468
I realized I didn't reference the BIND documentation section 4.2.28.4 Dynamic Update Policies (the external option), which is what's planned.
Post not yet marked as solved
Looks like building 1557.120.7 from the GitHub releases is pretty different, the latest doesn't have an Xcode target for dnsextd. The patch is much smaller, but the Makefile doesn't collect the conf, man page, launchd plist and executable and put them in an appropriate structure.
dnsextd.txt
Post not yet marked as solved
I'm interested to know why you haven't mentioned the NSServices definition in the app's Info.plist. Does it include the NSSendTypes you're looking for? Or was your app relying on an implementation detail that the pasteboard used to provide all available types to a service, rather than narrowing them by the accepted ones.
Post not yet marked as solved
You can already bridge interfaces or create VLANs in the Network preference pane - https://support.apple.com/guide/mac-help/MH43557/10.15/mac/11.0, by clicking the overflow/hamburger icon in the list, choosing Manage Virtual Interfaces, then choosing "+".
But if you're after a more virtual machine semantic, you may want to look into vmnet.framework, which can be implemented in code and run as root to serve various requests.
Post not yet marked as solved
Have you tried examining the pasteboard state using Clipboard Viewer from the Xcode Additional Tools - https://developer.apple.com/download/more/?
Post not yet marked as solved
How were you planning to describe the program's entry point to the linker? If this is taken from a code sample for another operating system, is it relying on some implicit GCC behavior?
Mach-O uses a load command (LC_UNIXTHREAD before 10.8 Mountain Lion, LC_MAIN afterwards) which indicates the entry point of the executable. When using ld, the symbol can be specified with -e (the man page - x-man-page://ld contains more details about default behavior).
Post not yet marked as solved
I use NetFSMountURLAsync quite a bit in code, but moved off AFP a while ago. Is there a particular reason you're not using SMB at this stage?
You might mention the error code returned, any options you're providing in the two arguments.
It's possible mount_afp processes the URL (ParseAFPURL and uamName) and sends the AUTH parameter as an option to mount(2). Technically such options should be supported by the keys in NetFS.h, but only the general ones are documented (and some like allow loopback are broken).
Sounds like what you really want is a "shared" search field that can delegate to the current view controller.
In that case you'd use a protocol which your view controller(s) conform to, then an API (possibly in your window controller) which inserts a search field (if it doesn't already exist, or discovers one using an identifier) and connects to the current view controller to send it the relevant messages and provide a reference. The view controller should "attach" then "detach" using the protocol, and the true ownership should be by e.g. the window controller.
You don't need a custom NSWindow subclass to declare storage and an outlet for NSToolbar, it already has a reference.
It's not entirely clear to me what you're trying to achieve. Is the goal to have a reusable view controller which discovers an NSSearchField located in the window containing the view?
If so, you should strongly consider using an identifier for the search field, which the view controller declares as a public constant. The contract then is the window (e.g. representing a document) contains its own arrangement and customization of the toolbar and field (which uses the identifier). At some point it has the view of this view controller inserted into its hierarchy. When that happens, viewWillAppear() or similar mechanism searches the toolbar of the view's containing window and locates the NSToolbarItem with its defined identifier. What it does with that reference is then up to you.
Normally IBOutlets and IBActions are used when there's a strong contract between the interface file and a class, usually the File's Owner. If you're looking to discover a view from a reusable class (like a view controller provided by a framework), something like an identifier or tag is a better "fit".
Regardless of the issue, you should use defaults delete to remove preferences from the current user, since the cfprefsd process will keep an in-memory copy of the data.
Post not yet marked as solved
Looks like you're doing two different things. Your command adds a certificate as "trusted", which usually isn't necessary unless it's self-signed.
In particular you're using the root user to modify the current user's keychain, which might have the effect of making it unreadable by that user
The file extension is cer which is not an identity.
An identity is a certificate and its private key together in one file, which is almost always encrypted with the extension p12.
Post not yet marked as solved
The provided method wouldn't be an image (whatever VMware does). A Google search for "macOS Mojave" (or other version) usually turns up a support page from Apple which has a Mac App Store link to the installer app. The app contains the createinstallmedia tool which can create the kind of image you're looking for.
For Mojave that page is How to upgrade to macOS Mojave - https://support.apple.com/en-us/HT210190, and the link is Get macOS Mojave - https://itunes.apple.com/us/app/macos-mojave/id1398502828?ls=1&mt=12
