You might encounter a warning when trying to run Bright CLI. Microsoft Defender SmartScreen might stop an app it doesn't recognize from starting.
To fix this, you can try these solutions:
- Click the Run anyway button on the Microsoft Defender SmartScreen warning screen.
- Go to the file's properties and check the box that says Unblock.
When you try to download and run Bright CLI that hasn't been officially verified, certain web browsers might alert you with a warning saying "Uncommonly Downloaded".
The file is blocked once it’s downloaded, and you see a Discard button next to it on the Downloads bar. Click the dropdown arrow next to it and select the Keep option. This will save the file to your local disk.
“file“ cannot be opened because its developer cannot be verified when attempting to run Bright CLI on macOS
When you try to download and run Bright CLI that hasn't been officially verified, macOS will prevent its execution and notify the message that "File cannot be opened because its developer cannot be verified".
To address this concern, refer to the guide available at: Running unsigned command-line binaries | Macintosh notes.
Another approach involves removing the quarantine attribute from the specific file(s) using the command:
xattr -d com.apple.quarantine /path/to/file
Alternatively, they can choose to disable the gatekeeper globally by executing the command:
sudo spctl --master-disable
"bad CPU type in executable" when attempting to run Bright CLI on an Apple silicon machine (darwin/arm64)
To use the CLI on an Apple silicon machine (darwin/arm64), you need to install Apple's Rosetta 2 software as follows:
"permission denied" error message when attempting to execute a downloaded executable on macOS or Linux
When you download an executable and try to make it work, the command shell might say permission denied. This means you're trying to use a file you cannot execute. To make it work, do this:
chmod +x ./path-to-file
"exec ./bright-cli: no such file or directory" when trying to run a glibc-compiled binary, like Bright CLI, on Alpine Linux
When attempting to run a glibc-compiled binary, such as Bright CLI (e.g.
bright-cli-linux-x64), on Alpine Linux, you may encounter issues due to the differences in the dynamic linker and shared dependencies. This can result in errors like:
exec ./bright-cli: no such file or directory
Alpine Linux uses the musl libc library, which is different from the glibc library used in many other Linux distributions. This difference in libc can lead to compatibility issues with shared dependencies when running executables on Alpine Linux.
To mitigate compatibility issues and run glibc-compiled binaries on Alpine Linux, you can install one of the glibc compatibility packages:
- libc6-compat: This package provides glibc compatibility, allowing glibc-based binaries to run on Alpine:
sudo apk add libc6-compat
- gcompat: Another option is the gcompat package, which provides compatibility with glibc's dynamic linker:
sudo apk add gcompat
The standalone executable runs successfully when executed manually but fails with an exit code when attempting to run it as a service. The systemd service status indicates an error pointing to SELinux preventing the repeater from running under the
init_t process context.
bright-repeater.service - bright-repeater Loaded: loaded (/etc/systemd/system/bright-repeater.service; disabled; vendor present: disabled) Active: failed (Result: exit-code) since <redacted unnecessary timestamp> Process 2101 ExecStart=/home/user/bright-cli (code=exited, status=203/EXEC) Main PID: 2101 (code=exited, status=203/EXEC)
The failure occurs because SELinux, in its default configuration, prohibits the execution of the repeater program located in the user's home directory (
user_home_t) under the
init_t process context.
- Move your program from the user's home directory to a standard binary directory, such as
sudo mv /home/user/bright-cli /usr/local/bin/
- Update the SELinux context labels to allow the execution:
sudo restorecon -Rv /usr/local/bin/
This step ensures that SELinux recognizes and permits the execution of the program from the new directory.
- Try restarting the service after moving the program and relabeling the new location:
sudo systemctl restart bright-repeater
Alternatively, you can consider compiling a custom SELinux policy if you prefer to keep the program in the user's home directory and need it to run from there.
"cannot execute binary file: Exec format" error when attempting to run a binary on a Linux/arm64 machine
To use the CLI on a Linux/arm64 machine, you need to install QEMU software as follows:
apt install binfmt-support qemu-user-static update-binfmts --display
For details, please refer to QemuUserEmulation - Debian Wiki.
Updated about 2 months ago