遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/237)
<a href="https://www.bestpractices.dev/projects/237"><img src="https://www.bestpractices.dev/projects/237/badge"></a>
Your Debian-based data center in a box
A collection of Ansible playbooks, scalable from one container to an entire data center.
DebOps Code Standards Policy
DebOps Quick Start guide.
The project documentation is included in the same repository as the project code. Any changes in the code are expected to be reflected in its documentation at the same time (in the same commit, or in the same pull request).
The Upgrade notes describe any changes that users have to perform to correctly upgrade the software.
The issue tracker of GitHub is currently used.
There were no vulnerability reports in the last 12 months.
The languages used in the project codebase (YAML, Python, Bash, reStructuredText, Ansible) are tested using linters and syntax checkers on Travis-CI before being merged, any issues found by the tests need to be resolved.
The project uses only interpreted languages in its codebase (Python, Ansible, Bash), no binaries are built.
The Ansible way to install and uninstall Ansible roles (which are a main part of the project) is by using the ansible-galaxy command line tool. This is supported by the project and all Ansible roles are published on https://galaxy.ansible.com/debops/ to allow easy usage of the project’s roles. ansible-galaxy is considered a commonly-used convention (in the Ansible community).
ansible-galaxy
The DebOps way to make full use of the project is to install the DebOps scripts and using debops-update to download all the required configuration management code to the Ansible controller (host which runs Ansible in order to do configuration management on remote hosts or the Ansible controller itself).
debops-update
Debian packages are work in progress.
The debops-update script, which can be used to install or update DebOps roles and playbooks, uses the `$XDG_DATA_HOME variable described in the XDG Base Directory Specification.
The project includes configuration for Vagrant which can be used to quickly and easily create virtual machines or LXC containers which can be used for project development and testing. The same infrastructure is used by the DebOps project in the GitLab CI pipeline for testing Ansible roles and playbooks.
DebOps heavily relies on Debian Archive repositories as its primary source of software. Versions of any upstream projects not included in the Debian Archive but installable by DebOps can be checked using the make versions command in the root of the project repository.
make versions
DebOps project targets the current stable release of Ansible and any deprecated or removed features are changed to meet the current requirements.
Travis-CI tests are applied to any and all pull requests to the main DebOps repository on GitHub. The tests have to pass before any pull requests are merged to the master branch.
master
Any warnings found by the linter tests are reported as errors, and need to be addressed before changes to the project can be merged.
Blame git for that! Sure the hash function was not initially design to be cryptographically strong but the project uses it as such! Ref: Code signing policy.
This criteria is currently not met for all parts of the project but is a work in progress:
debops.apt_cacher_ng
The project allows to use unencrypted network communication protocols but the user has to decide to enable them:
debops.smstools
Applies for debops.nginx and other parts of the project dealing with TLS.
debops.nginx
Verify if for example debops.postfix does this by default.
debops.postfix
All software configured by DebOps that deals with TLS encryption is set up to require a valid X.509 certificates signed by trusted Certificate Authorities. The project can create and maintain a local Certificate Authority which is automatically added to the hosts managed by DebOps as trusted to support inter-host communication on a secure channel.
The project's git tags as well as the tarballs released on GitHub are signed using the project maintainer PGP keys. The private keys are not published anywhere. The PGP keys used to sign the released are available in the PGP keyserver network for verification.
git
Work in progress. Examples:
debops-contrib.apparmor
Already supported:
debops.sshd
debops.tinc
debops.fail2ban
[and more]
See above.
All languages used in the project are memory safe. Web application scanner might make sense for web application deployments. This is currently not done.
后退