-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wfluxor #111
Conversation
PHPStorm fails (@nickygerritsen you always fix this?) |
Phpstorm you indeed need to manually copy. The readme contains information on how to do it. Hopefully someone else can do it this year while I’m not there yet |
provision-contest/ansible/roles/keepalived/templates/keepalived.conf.j2
Outdated
Show resolved
Hide resolved
Add intended final to naming, shortened naming for readability
There is not clean way to keep the playbooks the same and keep our generic variables. The structure: wf46 - domserver wf47 - domserver would get all variables from wf47 as that is the last defined hostgroup above domserver, putting the contest below would put all hosts (even judgehosts) in the domserver group. By symlinking we get the least worse solution as we have the variables, but for ansible those all look like new groups. Where possible we use the value from `all`, online is fully copied to make sure we don't pick any value from the onsite branch. Use default values for Luxor
We import our admin accounts in the analyst instance, using another password only makes this more difficult.
The replication password is set lower in the wf46/wf47 as besides the risk for leaking the database we would also setup replication on the analyst instance. The ICPC-tools variables are not relevant here as we at this point don't setup the CDS.
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
9997180 | Triggered | Username Password | 32f899b | provision-contest/ansible/group_vars/all/secret.yml.example | View secret |
9997181 | Triggered | Generic Password | 32f899b | provision-contest/ansible/group_vars/all/secret.yml.example | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secrets safely. Learn here the best practices.
- Revoke and rotate these secrets.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Our GitHub checks need improvements? Share your feedbacks!
We only need those on the domservers (& admin machines).
I thinks those are the changes which are needed during the WF, I'll setup some VMs on Calcb to let Nicky play with it.
This is not meant to be merged, but makes it easier to discuss possible changes.