Вадим

https://github.com/python-social-auth

Приветствую.
Прежде всего, не стоит представлять себе решение задачи, как "большую кнопку", т.к. наши представления об управлении инфраструкурой несколько извращены опытом работы с продуктами MS. Интерфейс скрывает от нас стек ПО используемого для достижения цели. Например, WSUS. Под его капотом находится набор служб, каждая из которых играет определенную роль - bits для загрузки на сервер и доставки пакетов на клиента, веб-сервер для управляющих команд, база данных для хранения состояния клиентов и исправлений, .net приложение, обьединяющее все это. Для парка nix машин вам предстоит построить подобную архитектуру самому, выбирая каждый раз инструмент, который будет играть ту или иную роль.
На втором шаге вам нужно посмотреть на задачу. Если у вас десяток инфраструктурных серверов, то Ansible действительно неплохой выбор. Но только не "скрипт". "Скрипт" - это язык, который говорит как достичь результата. Но инструменты управления конфигурацией избавляют вас от этого, с помощью декларативного языка вы описываете сам конечный результат(это ключевой момент) и не задумывайтесь о том, какой дистрибутив (читай менеджер пакетов, расположение конфигурационного файла) установлен на управляемой системе.
Если вам нужно дать доступ большому количеству пользователей к большому количеству машин, то на первом шаге вам нужно выбрать два инструмента:
1. управление конфигурацией.
2. управление sudo.
Первый инструмент с натяжкой может предоставить вам возможность решить пункт 2, т.к. в этом втором пункте вам нужно управлять теми самыми политиками: группе пользователей дать доступ на группу машин и разрешить выполнять группу команд. Здесь в игру вступает Identity Manager и этот вопрос для меня по крайней мере, открыт. Текущие тенденции ведут к развертыванию двух каталогов (MS AD и каталог для парка NIX), но не берусь сказать насколько это правильно. Обойтись без второго каталога можно и, если отбросить шелуху, то ключевой проблемой, в таком случае, является сопоставление идентификаторов безопасности пользователей в MS AD и в nix системах (просто когда один домен, сложнее когда лес, совсем не просто в случае созданных вручную доверительных отношений). Раньше этот вопрос решал winbind с набором библиотек, реализующих тот или иной алгоритм сопоставления, теперь это SSSD, реализующий два алгоритма. Опять же вопрос с выполнением привилегированных команд в такой конфигурации не решается. RedHat предлагает скомпанованные в единый продукт инструменты, которые, якобы эти задачи решают. Поддержкак от этого самого редахата стоит бешеных для нас денег, но вы посмотрите из чего состоят такие решения как Sattelit и IdM, это открытые продукты (FreeIPA, candlepin, pulp, katello, puppet и, наконец, foreman.) которые, возможно вам и нужны.

В итоге все таки установил zabbix. Отличная документация, все удобно.

Я не раз видел попытки такого разделения пользователей по классам в проектах на Django. Не знаю, почему все сразу выбирают такое решение, которое в перспективе не приносит ничего, кроме боли.

Проще всего пойти стандартным путем: унаследовать пользователя от django.contrib.auth.models.AbstractUser, а различие между пользователями определять либо по группе/разрешениям, либо добавить поле в свою модель типа is_moderator. Это будет во много раз (на порядок точно) проще реализовать и поддерживать, будет совместимость со всем стандартным кодом Django и сторонними библиотеками, любому просто войти в проект и внести изменения.

Разделение на две разных модели никаких абсолютно преимуществ не дает, кроме тонны мусорного кода и головняков с поддержкой данной гидры.

TLDR:
1) Из вашего вопроса остается неясным, почему требуется разделение по разным классам. Это самый безумный вариант для разграничения полномочий, и в Django разделение полномочий пользователей уже предусмотрено по умолчанию
2) Поддерживал пару проектов с разными классами для разных классов пользователей. Поверьте, это просто ужас-ужас в поддержке, а самое главное, что он ничем не оправдан.

TL;DR: Нет, не актуально, потому что не дает пройти регистрацию до конца.

Из-за отсутствия вменяемых объяснений насчет возможных ограничений, пришлось тупо попытаться зарегестрироваться. Оказалось, что на втором этапе нельзя пройти дальше, если не указать гражданство или резиденство в США. Так что, лажа это или нет, она гражданам РФ не актуальна.

Очередной сайт болеет популярной болезнью: он лезет туда, где сидят люди со всего мира, но не считает нужным сразу предупредить, что актуален лишь некоторым. Так сложно получить расположение по IP и вывесить предупреждалку, или что-нибудь в таком духе?

Это мне напоминает некоторые русские «интернет-магазины», которые предлагают жителю Волгограда «купить с бесплатной доставкой» их восхитительные товары, и только на самом последнем шаге заказа перед оплатой выясняется, что этот «интернет-магазин» не рассылает в «замкадье» даже платно. Ребята, кто разрабатывает сайты, не делайте так, ок?

https://gist.github.com/

Но какая разница? У вас ведь скрипты ещё и с базами данных общаются?
Предположим, написали вы сервис на чистом РНР без фреймворков, а для теста написали аналогичный сервис на Python/Django. Предположим, что на чистом РНР можно получить 10к запросов/сек, а на Django - жалкие 4к. Печаль.

Но ваш сервис, например, будет использовать 5 запросов к БД, каждый из которых будет отрабатываться за 1мс. 5мс - чисто на запросы к БД.

Итого: на РНР запрос будет выполняться за 5.0001мс, на Python/Django - за 5.00025мс... Неужели есть какая-то разница?

Переехал и не капли не жалею, Centos намного удобнее, чем Debian.
Теперь использую исключительно Centos, Debian только на одном десктопе (Но в приоритете для десктопа - Fedora)
Самый большой из плюсов - лайф цикл. Ещё в yum по умолчанию многое можно, чего нельзя в apt (search, localinstall, provides). А так же selinux и firewalld и помимо этого всякие мелочи для которых в Debian приходилось костылить (типа if-up/if-down для route/rule/iptables)

https://pythondigest.ru