Project

General

Profile

Actions

Feature #5954

closed

teuthology implicitly depends on /etc/security changes; could be more friendly if it didn't

Added by Dan Mick over 10 years ago. Updated over 10 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
% Done:

0%

Source:
other
Tags:
Backport:
Reviewed:
Affected Versions:

Description

Loïc discovered that teuthology (specifically the task runners) depend on changes to /etc/security to
allow adjust-ulimits to run and set unlimited core and 16K open files. These are currently hacked by
our ceph-qa-chef code: https://github.com/ceph/ceph-qa-chef/blob/f1c0aa840f26a9c1dbdbe9a7a07bcc34202ca900/cookbooks/ceph-qa/recipes/default.rb#L13 which sets up:

    ubuntu hard nofile 16384

and

fedora, centos, redhat edit /etc/security/limits.conf to allow soft coresize limits:

sed -i 's/^#\*.*soft.*core.*0/\*                soft    core            unlimited/g' /etc/security/limits.conf

as well as

    sed -i 's/ requiretty/ !requiretty/g' /etc/sudoers
    sed -i 's/ !visiblepw/ visiblepw/g' /etc/sudoers

and also set up /etc/security/limits.d/remote.conf to contain

*   hard    core   unlimited

(and actually those last two seem redundant, or at least weird that they exist in two
totally different places).

It seems like it would be cleaner if we just require the test user to be passwordless-sudo
(which I think we already do) and add appropriate sudo calls in the right places. Sage thinks
this might involve separating the ulimit calls in adjust-ulimits to "those that need unl core"
and "those that need nofile". Should probably also straighten out who needs the hard vs soft
core limit.

Actions

Also available in: Atom PDF