----------
ID: package_duo
Function: pkg.installed
Name: duo-unix
Result: False
Comment: Problem encountered installing package(s). Additional info follows:
errors:
- E: There were unauthenticated packages and -y was used without --allow-unauthenticated
System modules are enables by default. But they should only be enables if
in pillars defined and supported by os_family.
Support for Redhat os_family systems is missing in at and cron #174
https://gerrit.mcp.mirantis.com/25351/ was merged but linux.system.shell
state wasn't included into init.yml and was never used.
This commit fixes this.
Related-Prod: PROD-23581
Change-Id: I89e09247dd2566b8a5b0c0e67e8ca9c789ed57f6
The following parameters defined in /etc/login.defs can
be overridden per-user:
* PASS_MAX_DAYS
* PASS_MIN_DAYS
* PASS_WARN_DAYS
* INACTIVE
Related-Prod: PROD-18386
Change-Id: I5b182128f9dd8a043b48fb86e61febb2fd5c7e0a
* Ubuntu pinning params allow to be used
multiply times. In same time, old `list`
format now allowing to be predictable
iterated inside jinja
Related-Bug: PROD-21604 (PROD:21604)
Change-Id: If1c0f0f834a296b9a19d0af5fc7673c9229a7ac5
Permissions 640 root:root doesn't allow regular user to read
/etc/{at,cron}.allow files, that changes behavior of at / crontab
commands:
* crontab command can't read /etc/cron.allow and allow any user to modify
their crontab files.
* at command can't read /etc/at.allow and deny every user.
at / crontab files have SGID bits set, so setting correct group
on /etc/{at,cron}.allow fixes the issue.
Change-Id: I4a3fc8d8e823498d6715e26307424e3065cbd6ca
* CIS 5.4.4 Ensure default user umask is 027 or more restrictive (Scored)
* CIS 5.4.5 Ensure default user shell timeout is 900 seconds or less (Scored)
Related-Prod: PROD-20765
Change-Id: I5ff5e5bc76e1d87432caec70f2b35eec288e9213
linux/system/user.sls ignores 'shell' option if a
user is system. This is quite strange behavior, and it
breaks CIS:
* 5.4.2 Ensure system accounts are non-login
Change-Id: I32dd44ac4fcc1425ea47eb4cf60acf41f6ce0887
Related-Prod: PROD-20764
- Add possibility to remove prereq. packages installation BEFORE
* Crucial logic violation - if we don't have any repo\
have them configured in wrong way - stage will always fail.
* install prereq. packages after all - sounds stupid, but correct.
* By default - it will still try to install prereq. We don't want to
broke OLD logic.See readme, how-to overide such behaviour.
- don't update cache per-repo - it's simply useless and may fail due p1.
Run update only once - after all repos configured\reconfigured
- Add new option at system:refresh_repos_meta - for case, when update
should not be run in any case. By default - true.
- remove 99proxies-salt-{{ name }} along with disabled repo
- fix duplicate 'clean_file' option
Closes-Bug: PROD-15992 (PROD:15992)
Change-Id: I4b312f82f65be80e7726f62482978f68c25746a3
We create custom hugepages mount point for KVM/DPDK with custom
parameters (ownership flags/hugepages size). Need to disable default
mount point, because it can be unexpectedly used by DPDK.
Change-Id: Ibee95422213260e544406391c7a0922f1a41c5c2
Closes-Bug: PROD-14325
- fixed pkgrepo.manage to use/prefer key_url for salt >= 2017.7
- updated syntax for key verificatoin
- fix, avoid curl for salt:// schema (as in #156)
Change-Id: I1b50c287a4030a9cefa1b819017d59cc5fb1c197
Marek Knappe
pavel-z1
preussal
Irving Leonard
Bruno Binet
Nick Metz
Gleb Galkin
Gabor Orosz
Jaroslav Steinhaisl
Dzmitry Stremkouski
Dmitry Teselkin
azvyagintsev
Martin Polreich
Alexandru Avadanii
Ondrej Smola
Sergey Kreys
Petr Michalec
Vasyl Saienko
Martin Horak