иногда бывает что крайне очевидное решение крайне неочевидно. уже пару лет использую связку user name=... password=... authorized_keys .... и вот первый раз пользоватль захотел только пароль без ключа. оказывается ansible в поле password хочет шифрованный пароль....

уволить такого пользователя.

я бы понял ещё ключ без пароля, но пароль без ключа...

так этоже не сложно сделать....

Сделать не сложно

Просто если кто-то так же как я этого не знал -- делюсь опытом ошибки

Просто если кто-то так же как я этого не знал -- делюсь опытом ошибки

Сделай пользователю приятное - добавь параметр: expires

Сделай пользователю приятное - добавь параметр: expires

Рубрика вредные советы

а вот так хеш нормально генерить? python -c "import crypt,random,string; print crypt.crypt(raw_input('password: '), '\$6\$' + ''.join([random.choice(string.ascii_letters + string.digits) for _ in range(16)]))"

а вот так хеш нормально генерить? python -c "import crypt,random,string; print crypt.crypt(raw_input('password: '), '\$6\$' + ''.join([random.choice(string.ascii_letters + string.digits) for _ in range(16)]))"

зачем? я так делаю: - name: Add users user: name: "{{item.username}}" shell: /bin/bash groups: wheel append: yes password: "{{item.userpass |password_hash('sha512')}}"

ну да попроще будет :D ток вопрос в том что я например не должен видеть пароли людей

я храню юзеров в гите а пароли тупо рендомом делал.

ну у меня инвентори там где пароли - через ваулт зашифрованы, там что не принципиально хеш хранить и "открытые" пароли

зачем? я так делаю: - name: Add users user: name: "{{item.username}}" shell: /bin/bash groups: wheel append: yes password: "{{item.userpass |password_hash('sha512')}}"

А как рулишь пользователями - в смысле они все в одном файле списком?

А как рулишь пользователями - в смысле они все в одном файле списком?

у меня вся инфа по 1 хосту - в 1 файле (инвентори хоста)

Т.е. инфа о пользователе дублируется если он в нескольких хостах должен быть

Я вот от этого хочу уйти, один пользователь - одно описание, на все хосты

Т.е. инфа о пользователе дублируется если он в нескольких хостах должен быть

да, идея в том чтобы не лазить по куче файлов в поисках инфы: вся информация о хосте - в 1 файле, открыл его и все понятно

вообще идея упоавления уз через ансибл крайне неудачная

годится для систем где юзеров мала. 3-5

годится для систем где юзеров мала. 3-5

согласен, у меня не стоит задача управления юзерами, это только на этапе сетапа

вообще идея упоавления уз через ансибл крайне неудачная

нормальная идея, на хостах всё равно не должно быть более 5 пользователей, а вот хостов может быть много.

Ну не везде годно авторизовать по ldap

Я вот от этого хочу уйти, один пользователь - одно описание, на все хосты

тогда я бы вынес хешированный пароль в переменные для роли, которая этого юзера накатывает

нормальная идея, на хостах всё равно не должно быть более 5 пользователей, а вот хостов может быть много.

зависит...

вообще идея упоавления уз через ансибл крайне неудачная

какие проблемы возникают когда их много?

увольняются. меняют права. группы.

тогда я бы вынес хешированный пароль в переменные для роли, которая этого юзера накатывает

у меня оно вынесено, проблем в другом - как объединять переменные в словарь из разных файлов.

и как это делать ?через отдельный плейбук ? или через часть роли

увольняются. меняют права. группы.

группы в /etc/groups меняют? зачем??

если отдельный плейбук то как сделать что бы конкретному одному дать больше прав чем его группе

если через ролевые плейбуки то как обеспечить синхронизацию всего дела когда плейбуков множество

такие вот вопросы

увольняются. меняют права. группы.

наверное, это уже надо не через системных пользователей....

если отдельный плейбук то как сделать что бы конкретному одному дать больше прав чем его группе

xattr

или им всем нужен логин на сервер?

я про живых юзеров ваапщета.

я про живых юзеров ваапщета.

им всем нужен доступ на логин к серверу? или доступ к какому-то сервису?

ак и так и так

А каким местом управление пользователями хоста относится к управлению пользователями сервиса?

или речь о samba и иже с ним?

я про обычных системных пользователя. некоторые должны быть на хосте. бывает что там 100500 деволпсов и немного девов или путок опсов

и вот внутри этого дела бывает надо управлять правами юзеров

особено в мультипроектных системах

когда какой нить dba должен быть везде, но кое где рутом а гдето нет

и вот тут ансибл сливается очень

и надо кокой нить ipa

Ну не то что-бы сливает, просто задача у ansible проще, у меня для случая с dba решается разным экземпляром описания переменных для хоста или группы хостов. Если человек уволился - то смена пароля и ключей в файле описания юзера. Но так-то да централизовано оно получше будет, ну тут есть возможность накатить на хост авторизацию по ldap или использовать схему ansible pull.

годится для систем где юзеров мала. 3-5

где юзеров много, там LDAP у нормальных людей :)

там тоже бывают варианты

проблема еще в том что ансибл надо руками дёргать или пилить что-то вокруг

а не просто поставить галочку что челвоек уволен и права отобрались везде

проблема еще в том что ансибл надо руками дёргать или пилить что-то вокруг

Тут вам скорее salt нужен.

а не просто поставить галочку что челвоек уволен и права отобрались везде

git hook?

git hook?

Или так

Тут вам скорее salt нужен.

салт не надо руками дергать?

Нет

Нет

нет - не надо или нет - надо?

не надо, будет поддерживать заданное состояние

не надо, будет поддерживать заданное состояние

пока highstate не сделаете руками никто последнее состояние к вам не завезет, насколько я помню. может что поменялось конечно

пока это выглядит намного проще в реализации

ну а перед этим конечно надо сделать git pull а потом сделать salt state.highstate

выглядит это ровно точно так же как и с ансиблом с единственной разницей в салте есть зеромку в ансибле нет. если люди которым это нравится.

с другой стороны есть товариши который чеф по крону пускают, вот у них там полное удовольствие от поддержания последнего состояния...

я сейчас вообще тестирую foreman

концепция с ансиблом и раскатой из кучи мест вообще стрёмная, а централизовать не выходит когда у людей доступ есть

концепция с ансиблом и раскатой из кучи мест вообще стрёмная, а централизовать не выходит когда у людей доступ есть

а не должна ли раскатка иметь место по зелененькому в ci? а не потому что сегодня васе приспичило накатить...

когда у тебя всё классно сделано то конечно да

когда у тебя страшный огромный госпроект - боятся

ERROR: S client not available

там тоже бывают варианты

там нужно предварительно планировать, как именно и что именно делать

пользователи из LDAP - вещь. в "искаропки" можно сделать "разрешено всем", "разрешено только тем, кому разрешено", "разрешено только тем, кто входит в конкретную группу" на мой вкус - вполне достаточно.

не говоря уже о всяких фокусах, которые возможны с sudoers

ну вот кстати у меня есть один знакомый, у которого пользователи для windows/linux живут в LDAP. однажды после обновления LDAP он потерял доступ ко всем серверам.

(а причиной тому стал баг в контроллере LDAP)

ну ок, посмотрел я на выходных на солт, в целом приятно. но документация!

"три фора пять ифов - хуярим дальше"? ) (с)

где посмотреть список работающих ключей для профиля для salt-cloud например

ну т.е. кроме исходников

солт-клауд это вообще отдельная балалайка.

если я ничего не путаю.

ну вот кстати у меня есть один знакомый, у которого пользователи для windows/linux живут в LDAP. однажды после обновления LDAP он потерял доступ ко всем серверам.

blue green deployment и "тестируй, что обновляешь", он для недостаточно глупых и недостаточно смелых, понятное дело :)

вот, кстати, есть у меня один знакомый (с) у которого как-то было всего лишь 90 тысяч учеток в LDAP, так приходилось все проверять, перед тем, как обновить :)))

blue green deployment и "тестируй, что обновляешь", он для недостаточно глупых и недостаточно смелых, понятное дело :)

согласен, да. тесты там были конечно же, но не совсем полные. проблемы начались через несколько часов, когда перегрузили два серванта и обнаружили что аутентификация в LDAP отпадывает после ребута.

ну мне солт как раз понравился этим salt-cloud и salt-ssh у меня масштабы очень маленькие, поэтому не вижу смысла держать еще и мастер

салт клауд прекрасно заменяет терраформ если вам надо в облака.

я облака до этого ансиблом собсно и строил, не знаю зачем терраформ

я облака до этого ансиблом собсно и строил, не знаю зачем терраформ

+ (AWS)

у меня тут амазон, опенстэк со вкусом рэкспейса и немножко вмварь виклауд чтоб жизнь малиной не казалась.

я из-за последнего и начал смотреть в сторону salt-cloud, потому что он объявлен диприкейтед ансиблом (да и вмварью). как заказчик сегодня сказал что наверное и оттуда будем съезжать.

пользователи из LDAP - вещь. в "искаропки" можно сделать "разрешено всем", "разрешено только тем, кому разрешено", "разрешено только тем, кто входит в конкретную группу" на мой вкус - вполне достаточно.

и что брать? у freeipa обычные болячки openldap, есть какое-то решение хотя бы полукоробочное где база не разваливается?

и что брать? у freeipa обычные болячки openldap, есть какое-то решение хотя бы полукоробочное где база не разваливается?

UCS

Они раньше платные были, но два или три года назад ушли в opensource. Мне нравится

как у вас получалось развалить базу openldap, расскажите?

зачем нужны freeipa, кстати. в смысле зачем вообще нужны все эти наслоения гамна, кроме чистого openldap

Openldap меняет scheme при смене версий. Обновляешься и поиск объектов из систем которые подключаются к openldap перестает работать

c 2.х на 3.x чтоли?

да его вроде нет ещё 3.х

и что брать? у freeipa обычные болячки openldap, есть какое-то решение хотя бы полукоробочное где база не разваливается?

вон ReOpenLDAP пользуй - в мегфоне стоит и не разваливается, даже в multi-master

ну значит мне везло, потому что у меня было минимум стандартных схем

это не коробочное решение, не охота с этим из консоли работать, морду самому писать?

ой, всё... я схемы сам делал, но тут даже "морду самому писать" боятся - другой use case