You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Homebrew installs packages to their own directory and then symlinks their files into /opt/homebrew (on Apple Silicon).
Proposal: The brew --prefix command could be used for paths to avoid inconsistency. It always points to homebrew's root directory independent of platform or installation directory. For paths it should expand to the correct directory, e.g.: zsh -> ls "$(brew --prefix)/var/lib/clamav"
The _clamav / clamav user already exists in the latest versions of macOS (from Sonoma 14 at least). It's used by SPAM Assassin / Amavis.
Proposal: For the macOS I'd rename the user _clamavd as it's conventional for service-related users to start with an underscore (_) and customary that they end in d to symbolize their purpose. I reckon this may be an issue as you assume the clamav user will be available or named as such, regardless of platform, on other parts of the documentation... Maybe a note can be left warning users of the name conflict, suggesting _clamavd to respect conventions, but making clear this may need to be taken into account when reading the docs.
3a. Potentially conflicting user ids
No ranges are suggested when prompting the user to select an available user id. This could potentially lead to issues with the os.
Rules for allocation are not described in-depth on apple's documentation. Some ranges are defined though on official documentation which I'll link below: Server Management Manual
The user ID 0 is reserved for the root user. User IDs below 100 are reserved for system use; users with these user IDs should not be deleted and should not be modified except to change the password of the root user. If you do not want the user to appear in the login window of computers with Mac OS X version 10.4 or later installed, assign a user ID of less than 500.
On macOS this concept is known as a role account. You can set one up using sysadminctl with the -roleAccount option.
A few key points to take from this:
a. Role (service) accounts should start with an underscore (_) and their UID's be set on the 200 to 400 range.
b. For user accounts not to be visible on the login window their UID's need to be below 500 range.
c. UID's below 100 are reserved for system use.
Proposal: I'd suggest users to look for an available UID on the 200 to 400 range. In my experience, and from information i've gathered from unofficial sources, 200 to 300 hundred seems to be used by osx for static daemon-related users, while the 300 to 400 range for dynamic (third-party and post-install) daemon-related users.
3b. Potentially conflicting group ids
In the same manner as above, no ranges are suggested when prompting the user to select an available group id. While there doesn't seem to be an official reserved range for group ids, there seems to be pre-assigned ranges, and groups also follow the underscore (_) convention for daemon-related users. I did find a response on serverfault which seems to fit the current allocation on my machine. Serverfault
OS X conventionally uses different ID ranges for different types of accounts. Here's the current layout as I understand it:
up to 100: Reserved for static system-defined (built in) groups
101 - 199: Used by the OS for dynamically-created groups (e.g. share point access groups)
200 - ?: More static system groups (apparently 100 wasn't enough)
400 - 500: More dynamic system groups
501 and up: Local admin-created groups
1024 and up: Domain-based admin-created groups
Proposal: I'd suggest users to look for an available UID on the 400 to 500 range.
4. Readability improvements to ID finding command
I'd make some tiny changes to the find command for user and group id's.
This keeps the outputted information the same, but the most relevant part (ID's) first, which makes it much easier to read.
It also tabulates the output for improved readability and adds a pager to avoid clogging the terminal with a long list of users.
5. Outdated and/or incorrect user creation commands
While using the directory service's cli for user creation still works the recommended way of managing users on macos is through the sysadminctl command.
Proposal: I'd replace the user creation commands with a single sysadminctl command which takes care of creating the Directory Service records and implicitly handles the nuances of role accounts such as setting the shell to usr/bin/false (also incorrect on the ClamAV docs) and home directory to var/empty
Launchd is the recommended tool for registering and scheduling services under macos. Proposal: While binary path may change depending on install method, maybe a template could be included in the macos service or configuration section with instructions on how to load it.
Note: homebrew includes a service definition, intended to be used through brew service start clamav, however homebrew is limited internally to a single service definition, in this case clamd (which in addition seems to be incorrectly defined), furthermore homebrew lacks internal support for defining UserGroup, UserName, and possibly StartInterval on its services plist generation.
Let me know what you think, I'm a bit short on time but i might be able to psuh a PR.
The text was updated successfully, but these errors were encountered:
There are a few improvements that could be made to the documentation for macOS users.
Some are simple fixes, some may require a bit of discussion.
Installing/Packages
1. Partially wrong paths for homebrew installation
Homebrew no longer uses
/usr/local
on Apple Silicon, it now lives under/opt/homebrew
Homebrew's Homepage:
Proposal: The
brew --prefix
command could be used for paths to avoid inconsistency. It always points to homebrew's root directory independent of platform or installation directory. For paths it should expand to the correct directory, e.g.: zsh -> ls "$(brew --prefix)/var/lib/clamav"Installing/Add clamav user
2. Conflicting daemon username
The
_clamav
/clamav
user already exists in the latest versions of macOS (from Sonoma 14 at least). It's used by SPAM Assassin / Amavis.Proposal: For the macOS I'd rename the user
_clamavd
as it's conventional for service-related users to start with an underscore (_) and customary that they end in d to symbolize their purpose. I reckon this may be an issue as you assume theclamav
user will be available or named as such, regardless of platform, on other parts of the documentation... Maybe a note can be left warning users of the name conflict, suggesting _clamavd to respect conventions, but making clear this may need to be taken into account when reading the docs.3a. Potentially conflicting user ids
No ranges are suggested when prompting the user to select an available user id. This could potentially lead to issues with the os.
Rules for allocation are not described in-depth on apple's documentation. Some ranges are defined though on official documentation which I'll link below:
Server Management Manual
Man pages
On "role accounts" from apple forums
A few key points to take from this:
a. Role (service) accounts should start with an underscore (_) and their UID's be set on the 200 to 400 range.
b. For user accounts not to be visible on the login window their UID's need to be below 500 range.
c. UID's below 100 are reserved for system use.
Proposal: I'd suggest users to look for an available UID on the 200 to 400 range. In my experience, and from information i've gathered from unofficial sources, 200 to 300 hundred seems to be used by osx for static daemon-related users, while the 300 to 400 range for dynamic (third-party and post-install) daemon-related users.
3b. Potentially conflicting group ids
In the same manner as above, no ranges are suggested when prompting the user to select an available group id. While there doesn't seem to be an official reserved range for group ids, there seems to be pre-assigned ranges, and groups also follow the underscore (_) convention for daemon-related users. I did find a response on serverfault which seems to fit the current allocation on my machine.
Serverfault
Proposal: I'd suggest users to look for an available UID on the 400 to 500 range.
4. Readability improvements to ID finding command
I'd make some tiny changes to the
find
command for user and group id's.Proposal:
This keeps the outputted information the same, but the most relevant part (ID's) first, which makes it much easier to read.
It also tabulates the output for improved readability and adds a pager to avoid clogging the terminal with a long list of users.
5. Outdated and/or incorrect user creation commands
While using the directory service's cli for user creation still works the recommended way of managing users on macos is through the
sysadminctl
command.Proposal: I'd replace the user creation commands with a single
sysadminctl
command which takes care of creating the Directory Service records and implicitly handles the nuances of role accounts such as setting the shell tousr/bin/false
(also incorrect on the ClamAV docs) and home directory tovar/empty
6. Missing launchd .plist
Launchd is the recommended tool for registering and scheduling services under macos.
Proposal: While binary path may change depending on install method, maybe a template could be included in the macos service or configuration section with instructions on how to load it.
Note: homebrew includes a service definition, intended to be used through
brew service start clamav
, however homebrew is limited internally to a single service definition, in this case clamd (which in addition seems to be incorrectly defined), furthermore homebrew lacks internal support for defining UserGroup, UserName, and possibly StartInterval on its services plist generation.Let me know what you think, I'm a bit short on time but i might be able to psuh a PR.
The text was updated successfully, but these errors were encountered: