Артём Брыкин

VCode + plugin SSH remote

Samson C01U Pro
П. С. Наверно, уже поздно :)

Буду краток. Она просто другая. А так как софт пишется для работы в линукс окружении, то и писать лучше сразу под линукс.

Я бы предложил сразу практику:
Поставить гипервизор, развернуть и настроить виртуальные Linux-машины с классическими корпоративными сервисами: почта, АТС, мессенеджер, веб-сервер, файловое хранилище с авторизацией.
Настроить везде бэкапы, самописными скриптами выгружать дампы БД, делать архивы конфигураций и контента.
После нормального конфигурирования остаётся траблшутинг, но он возможен только при какой-то пользовательской нагрузке.
А прохождение теоретического курса можно отложить или идти параллельно.

Потерять можно все при любом действии и любым продуктом.
Терраформ просто позволяет сделать это .. красиво и очень удобно, если вы хреново его спланировали.
Правило 1: используйте автоприменение только в тех местах где не жалко или где вы железобетонно уверены(и берете риски на себя)
Правило 2: валидируйте план. Хотя бы глазами
Вообще, есть у некоторых людей практика делать план в файл, валидировать его какой то внешней логикой, и при успешной валидации применять план из файла, не просчитывая его заново (он делается при каждом апплае) с автоподтверждением. Мне не нравится, да и терраформ честно предупреждает что на момент реального применения ситуация может отличаться и менять придется совсем другие элементы.
Правило 3: разноси элементы по логическим слоям, чтобы уменьшить зону поражения при гибельном апплае. Например настройки сети а одной папке со своим стейтом, запуск приложения - в другой. И связывайте через ремоут стейт. Главное соблюдать меру, чтобы каждую, скажем , security group в aws не создавать в отдельных слоях.
Правило 4: используйте модули, если применение логической группы ресурсов используется более одного раза. Тут тоже не стоит плодить модули на каждый ресурс и подходить разумно.
Правило 5: тестируйте изменения! (Используя одни и те же модули для стейжа и прода). Логично предположить что если вы снесли стейж то и прод снесется.
Правило 6: используйте vcs для работы с кодом терраформ (для того чтобы откатывать код для восстановления убитого стейжа например)
Правило 7: используйте lifecycle политики Prevent destroy на ресурсах, чтобы запрещать из убиение
Помидор 7.1: используйте ignore changes там где это нужно
Правило 8: используйте правильный инструмент для того что вы хотите сделать. Терраформ умеет много чего, но конфигурейшн менеджер он не заменит, хотя по функциям они чуть да пересекаются.

В принципе, если продолжать я могу до штук 20 дойти полезных советов, но на 90% мои правила, по сути - используйте для работы с кодом терраформ те же правила что и для работы с любым другим кодом - снимете 70% проблем. Остальные будут связаны с особенностью работы терраформ и радиусом кривизны рук автора терраформ кода.

P.S. пишу на ходу в метро, орфографию и пунктуацию правит т9. Спрашивайте, вдруг заметите какой нибудь термин, который я писать не собирался :D

Пробежался по оглавлению, и увидел, что в ней в принципе рассказывают основы linux, и задумался, стоит ли начинать погружение в linux с Kali Linux и с этой книгой?

Если Вы новичок в линуксе, то ДА можно начать с этой книге, так как там описываются такие простые вещи как создать каталог или перейти в другую папку, а потом уже начинается описание непосредственно самого Kali и специфичных для него вещей, таких как политики, репы, инструменты для пентестинга и т.д.
Если же Вы уже знакомы с линуксом, то эта книжка Вам не очень то и поможет. Можно конечно ее купить и в бумажном виде, если Вы так любите бумажные книги. Она на русском языке, если это принципиально.
Но если честно, то немного странно изучать администрирование именно с Kali Linux, так как дистрибутив предназначен для пентестеров и специалистов по информационной безопасности, а не для администраторов.

Вы бы начали лучше обучение администрированию с Debian или CentOS.

Я бы Вам посоветовал начать изучать администрирование вот с этих книг:
Brian Ward - Внутреннее устройство Linux (для профессионалов).
Evi Nemeth, Garth Snyder, Trent R. Hein, Ben Whaley - Unix и Linux. Руководство системного администратора.
М. Кофлер - Linux. Установка, настройка, администрирование.

Ну а если так хочется изучать Kali то нужно приготовиться что это дистрибутив не для новичков, а для опытных и там многие вещи немного не так работают как например в обычном Debian. Хотя он и основан на нём.

P.S. в целом Kail не плох, если знать как его приготовить :)) По своему опыту скажу, у меня он стоит уже год и полёт нормальный.

Для эксча - только SAN, потому что в нем должны быть такие домены как owa и autodiscover - иначе нифига работать не будет. Если уложитесь в пять доменов - обычно в SAN-сертификате пять входит в стоимость - хорошо, если нет - придется либо отдельные сертификаты брать (тут можно брать на LE), либо доплатить. Дает ли LE SAN-сертфиикаты - не знаю.
EV-сертификат для Вас бесполезен - это в основном понты, Вам понадобится OV - SAN-сертификаты не бывают DV.

Все снес, заново настроил.
Проблема была не только в сокете, это расхождение в конфиге уже потом произошло, когда выискивал причину.
Дело было в том, что в DNS запись неправильно сохранялась. Почему то ни один чекер не видел проблему с пробелами, кроме этого https://app.dmarcanalyzer.com/dns/dkim.
В общем всем было ок изначально кроме неверной записи в DNS.

Способа 3:
1. Купить облачный сервис вроде мастадонта Symantec.Cloud или что то меньшее более дешевое, но не менее эффективное (в этом и заключается ваш труд - найти такого)
2. Купить локальный софт - несколько лет назад хорошее впечатление оставил ORF - отечественный разработчик
3. Купить VPS на *nix, настроить там postfix + dnslbl + SpamAssassin

Третий способ самый недорогой. Но требует квалификации.
PS
А, да. Ни один из способов не гарантирует 100% защиты от спама и ложных срабатываний. Идёт постоянная борьба, покуда почтовый протокол не видоизменится.

Начните с первой ошибки. У вас, судя по всему, неправильно прописана PTR-запись.
Если у вас статический IP, то обратитесь к своему провайдеру, чтобы PTR для вашего IP-адреса указывал на ваше доменное имя.
Если у вас динамический IP, то, опять же, обращайтесь к провайдеру за получением белого статического адреса.

Видимо, импорт был из imap-аккаунта, при этом у папок остаётся специфический тип, надо исправить свойства.
https://www.slipstick.com/developer/code-samples/c...

Я экспортирую так

Get-User -RecipientTypeDetails UserMailbox | where {$_.UseraccountControl -notlike “*accountdisabled*”} | Select Name,WindowsEmailAddress,SAMAccountName,FirstName,LastName | Export-Csv c:\1\contacts.txt -Encoding unicode

А импортирую так

Import-Csv "C:\1\contacts.txt" | ForEach-object { New-MailContact -Name $_.Name -externalEmailAddress $_.WindowsEmailAddress -Alias $_.SAMAccountName -FirstName $_.FirstName -LastName $_.LastName -OrganizationalUnit "Contacts" }

Файл contacts.txt - это csv на самом деле

Привет!

1. Нет, нет необходимости в локальном AD.
2. И с облачной и с локальной.
3. CALы необходимы для обычной AD. Если у вас только Azure AD, то классические CALы не нужны. Но нужны те или иные лицензии, связанные либо с Azure либо с Office 365.

Рекомендую ознакомиться:
https://docs.microsoft.com/en-us/office365/enterpr...
https://docs.microsoft.com/en-us/azure/active-dire...
При связке наземная AD+Exchange Online (Office 365) Azure AD выступает посредником.
Синхронизируется всё это через Microsoft Azure Active Directory Connect

Как всегда - всё индивидуально и зависит от вашего окружения. В кратце - если у вас мало пользователей, скажем до 50, то пока вам будет достаточно лишь Exchange Online. Если больше или планируется быстрый рост, я бы задумывался про развёртывание собственной службы каталогов (AD). Локальную или облачную, опять же решать вам, отталкиваясь от своих задач.

Если будут дальнейшие вопросы - спрашивайте. Я с этим делом уже достаточно поковырялся.