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

🟢 Свой почтовый сервер на базе Postfix + Dovecot – моя статья по настройке типового почтового сервера на Linux.

Серверы только в виде Docker контейнеров:

🟢 Mailu – классический стек на базе Postfix + Dovecot + Roundcube + Rspamd + Clamav и т.д. Свой удобный веб интерфейс администратора. Для установки есть готовый конфигуратор, который формирует docker-compose.yml и .env для запуска. Хорошее решение для тех, кому нужен стандартный почтовый сервер, запущенный в Docker.

🟢 Mailcow – похожий на Mailu почтовый сервер на базе того же стека, но чуть более функциональный. В качестве веб клиента используется SOGo, есть ActiveSync, интеграция с Netfilter, поддержка TFA и TOTP. У проекта более навороченная админка, где можно управлять не только почтовым сервером, но и самой системой, контейнерами.

☝️Оба сервера хороши. Кому нужно попроще, берём Mailu, кому понавороченней - Mailcow.

▪️Docker Mailserver – ещё один стандартный стек на базе Postfix + Dovecot. Особенность сборки - максимальная простота и минимум своих наработок. СУБД не используется, пользователи хранятся в файлах, все сервисы используют стандартные конфиги. Потребление ресурсов минимальное.

▪️Poste.io – тоже на базе Dovecot + Roundcube и т.д., только вместо Postfix используется Haraka. Админка своя, уникальная. Весь проект упакован в один контейнер. Есть отдельно платная PRO версия, куда перенесена часть полезной функциональности. Я не увидел у него преимуществ перед Mailu и Mailcow, поэтому рекомендую их.

Серверы под Windows:

▪️hMailServer – очень простой в настройке почтовый сервер. Проект старый и популярный. Особых наворотов нет, только базовые возможности почтового сервера. Подойдёт для тех, кому нужен простой бесплатный сервер под Windows, для настройки которого не нужны особые навыки. Есть интеграция с AD.

Серверы на базе Postfix и системных пакетов:

▪️Iredmail – классическая сборка на базе Postfix + Dovecot и всего остального по списку. В плане функциональности бесплатная версия не представляет из себя ничего интересного, но проект популярен за счёт своего возраста. На момент появления имел автоустановщик в виде готового скрипта и веб интерфейс администратора. Сейчас при наличии других бесплатных серверов не вижу особого смысла в его использовании.

▪️Mail-in-a-Box – по сути аналог Iredmail, только без ограничений бесплатной версии. Установка через скрипт под Ubuntu. Пользователи хранятся в sqlite, админка - PostfixAdmin. Простой стандартный стек на базе open source компонентов. Минус - проект одного человека.

🟢 Modoboa – ещё одна стандартная сборка со своей админкой и веб клиентом на Python. Приятная особенность - встроенный мониторинг и отчёты.

Собственные разработки почтовых серверов:

▪️Stalwart Mail Server – современный и очень функциональный почтовый сервер. Есть поддержка протокола JMAP. Единая админка для бесплатной и коммерческой версии, где перемешаны возможности. Неинтуитивная настройка, малая известность. Один из самых функциональных open source решений.

▪️Carbonio CE – сервер от компании Zextras, которая писала и продавала расширения для Zimbra. После того, как последняя перестала собирать свои бесплатные бинарные сборки, Zextras решили сделать свой сервер и перенести свои наработки. Несмотря на то, что он построен на базе Postfix и Dovecot, вынес его в свою разработку, так как он сильно разбавлен кодом в виде расширений самой Zextras и Zextras Webmail (форк Zimbra Webmail). По сути это не только почтовый сервер, а проект для совместной работы. Отзывов про него мало, в основном не очень.

🟢 Mox – почтовый сервер из одного бинарника на Go. Максимально простая и быстрая настройка. Только базовая функциональность почты. Подойдёт для небольших или разовых задач.

Серверы только для рассылок:

◽️Mailman
◽️Cuttlefish
◽️Postal

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#подборка #mailserver

С системным временем в Linux с одной стороны всё просто - установил и запустил какую-то службу для синхронизации и дальше всё работает автоматически. Например службу systemd-timesyncd, chrony или ntp. А с другой - есть множество нюансов, которые в основном связаны с особенностями systemd.

В целом, любой из способов задачу решает, но иногда возникают небольшие проблемы. Например, бывают виртуалки, которые со старта имеют сильный сдвиг по времени - 2-3 минуты, или даже больше. Я не знаю, с чем конкретно это может быть связано. Наблюдал и на арендованных виртуалках, и на своих. Служба синхронизации времени исправляет эту погрешность, но в зависимости от системы и настроек в ней, служба синхронизации времени может стартануть после другой службы. В итоге в логах после загрузки системы некоторое время может быть небольшая путаница, пока все службы не получат актуальное время.

Заметил ещё такую особенность. Служба chrony в Debian как правило со своими стандартными настройками запускается и отрабатывает раньше всех, а вот в Ubuntu - нет, хотя настройки юнитов вроде как схожи. Но я не разбирался детально. В systemd не так просто разобраться. Много нюансов и ссылок с зависимостями юнитов, таргетов и т.д. А если взять службу systemd-timesyncd, то она по умолчанию может довольно поздно запуститься. Я последнее время именно её использую, чтобы не ставить лишних пакетов в систему, но по факту chrony удобнее и функциональнее.

Эту проблему частично можно решить простым хаком в лоб. Ставим chrony и создаём службу, которая будет стартовать раньше всех остальных, один раз запускать синхронизацию и выключаться. А дальше уже всё остальное будет загружаться как обычно. Не нужно будет лезть в потроха systemd и разбираться в настройках и зависимостях стандартных служб.

# apt install chrony
# systemctl edit --full --force chrony-once-sync.service

[Unit]
Description=Chrony one time sync and exit
Wants=network-online.target
After=network-online.target
Before=multi-user.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/chronyd -t 10 -q
RemainAfterExit=True
[Install]
WantedBy=multi-user.target

# systemctl enable chrony-once-sync.service

Можно посмотреть зависимости служб:

# systemctl list-dependencies --after

Chrony-once-sync.service должна стоять первой в списке multi-user.target. Перезагружаемся и проверяем. Смотрим, как отработала служба:

# journalctl -u chrony-once-sync

Также можно посмотреть весь лог загрузки и убедиться, что chrony-once-sync.service отработала раньше всех остальных. Практически сразу после активации сети.

# journalctl

Не претендую на полноту и правильность решения. Решил задачу, как говорится, в лоб. Более правильным было бы разобраться с зависимостями служб. Например, выставить службам, критичным к точному времени зависимость от chrony:

[Unit]
After=chrony.service

Хотя тут правильнее было бы привязаться к специальному таргету, который придуман для этих задач - time-sync.target. Можно использовать его в зависимостях, но надо внимательно смотреть, что все остальные зависимости с этим таргетом корректно настроены.

В этом случае придётся вручную каждый раз разбираться со службами, а с одноразовым юнитом можно особо не заморачиваться. Он просто запустится раньше всех и если служба точного времени у вас локальная, отработает очень быстро, остальные сервисы уже подхватят точное время. При этом такое решение подойдёт для разовой начальной синхронизации, а дальше можно использовать любые другие службы, не обязательно chrony. Или вообще не использовать, если запускаете какое-то одноразовое окружение.

☝️ Представленный юнит можно использовать как заготовку для других подобных задач с разовыми задачами раньше всех остальных служб.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#systemd

Есть небольшой и неприметный сервис, который может очень существенно помочь в отладке различных HTTP запросов. В контексте тематики канала он может помочь в создании и отладке мониторинга. Речь пойдёт о httpbin.org. Это публичный сервис, который можно использовать как по указанному адресу, так и запустить у себя локально:

# docker run -p 80:80 kennethreitz/httpbin

По главной странице сервиса не совсем понятно, как его использовать. Я покажу сразу на примерах. Допустим, вы настраиваете мониторинг сайта или API. Вам нужно проверить работу различных триггеров. Например, на код ответа 404. Чтобы получить от httpbin код ответа 404, обращаемся к нему по адресу:

# curl -I "https://httpbin.org/status/404"
HTTP/2 404

Соответственно, если вам нужен другой код, то просто меняете его:

# curl -I "https://httpbin.org/status/501"
HTTP/2 501

Аналогично можно тестировать ответы с заданными заранее заголовками. Проверяем ответ с заголовком Server=httpbin

# curl "https://httpbin.org/response-headers?Server=httpbin"
{
 "Content-Length": "92",
 "Content-Type": "application/json",
 "Server": "httpbin"
}

Идём далее. Тестируем триггер на время ответа сервиса. Например, проверяем работу при задержке более 3-х секунд:

# curl "https://httpbin.org/delay/3"

Получите тестовый ответ с задержкой в 3 секунды. Можно проверить с помощью time.

# time curl "https://httpbin.org/delay/3"

Учимся принимать поток из нескольких строк. В данном случае трёх:

# curl "https://httpbin.org/stream/3"

Получите 3 разных строки с json.

Принимаем картинку:

# curl "https://httpbin.org/image/png"
# curl "https://httpbin.org/image/png" --output picture.png

Сервис много всего умеет. Посмотрите на главной странице, открывая раскрывающиеся списки. Я привёл самые ходовые на мой взгляд примеры при настройке типового мониторинга. А так там поддерживаются и разные методы, и динамические списки, и разное сжатие, и куки, и кодирование и т.д.

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

⇨ 🌐 Сайт / Исходники

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#мониторинг

Для тех, кому в консоли достаточно обычного bash, могу порекомендовать ресурс, с помощью которого можно быстро настроить себе prompt. Для тех, кто не знает, что это такое, поясню. Promt – это информация, которая отображается в командной строке перед полем с вводом своей команды. Его называют приглашением командной строки.

Стандартный promt чаще всего user@host-name:current-directory# . С помощью сайта bash-prompt-generator.org можете легко его изменить, просто собрав как в конструкторе те элементы, что вам нужны. И тут же на сайте видно, как будет выглядеть приглашение командной строки.

Из того, что обычно добавляют, отмечу следующие вещи:

- отображение IP адреса сервера
- подсветка промта разными цветами на разных серверах
- подсветка промта красным цветом при работе от root
- вывод времени

Немного поигрался в конструкторе и собрал следующий промт:

[username@hostname.com|192.168.1.100] 20:32:03 (~/bin)$ █

PROMPT_COMMAND='PS1_CMD1=$(ip route get 1.1.1.1 | awk -F"src " '"'"'NR == 1{ split($2, a," ");print a[1]}'"'"')'; PS1='[\[\e[38;5;196m\]\u\[\e[0m\]@\H|${PS1_CMD1}] \t (\[\e[4m\]\w\[\e[0m\])\$ '

Теперь эту команду надо добавить в ~/.bashrc и применить изменения:

# source ~/.bashrc

В данном случае мы настроили promt у конкретного пользователя. Я цвет имени пользователя сделал красным, потому что это root. Для остальных пользователей promt можно вообще не менять, либо задать индивидуальный. Общие же настройки для всех пользователей живут в системном файле /etc/bash.bashrc.

Если у вас какой-то прикольный и необычный promt, поделитесь, пожалуйста, информацией.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#terminal #bash

В разное время на канале выходили публикации на тему логирования действий пользователя в терминале, в частности при подключениях по SSH. Тема востребованная, актуальная, так что решил все заметки по ней собрать в одном месте. К тому же решения предлагались очень сильно разные. Будет полезно их увидеть и сравнить в одном месте, от самых простых, до больших корпоративных систем.

◽️Snoopy — небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов. Продукт простой в настройке, живой, обновляется. Приехал в базовые репозитории популярных дистрибутивов. Работает сам по себе, без необходимости менять настройки SSH или пользователей.

◽️Log-user-session — программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл. Продукт старый, не поддерживается, но продолжает работать. Подключившись по SSH пользователь никак не закроет log-user-session и не выполнит команду мимо неё. Его просто отключит от сервера.

◽️PROMPT_COMMAND — использование встроенных возможностей оболочки bash. Содержимое переменной PROMPT_COMMAND выполняется после каждой введённой интерактивной команды. Мы просто выполняем команду history 1, которая показывает последнюю введённую команду и куда-то записываем её: в файл или syslog. Решение максимально простое и понятное, но со своими нюансами. Надо промты менять и следить, чтобы обратно не менялись.

◽️Sshlog — работает как отдельная служба, умеет не только логировать действия пользователей по SSH, но и слать уведомления, в том числе на заданные действия, собирать метрики по подключениям, осуществлять внешний доступ к открытым сессиям пользователей. Программа в своё время была сделана добротно и законченно, с сайтом и документацией, но потом разработку как-будто забросили.

◽️Tlog — современная программа от RedHat с полным названием Terminal logger. Поддерживает различные хранилища для логов: текстовые файлы, syslog сервер, журнал systemd или в elasticsearch. Формат - json, то есть удобно делать поиск и выборку. Разработана для интеграции в экосистему Redhat, поддерживает интеграцию с FreeIPA через SSSD. Есть в базовых репозиториях.

◽️Teleport — масштабная система по управлению удалённым доступом к закрытым от внешнего доступа системам. В том числе осуществляет управление SSH соединениями с помощью своего приложения для установления соединений. Умеет записывать сессии не просто на уровне перехвата команд и вывода в консоль с хранением в текстовом виде, но полноценно записывает сессию, которую можно воспроизвести в режиме реального времени.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#ssh #logs #подборка

Я уже ранее делал заметку насчёт LVM, где пояснил, что чаще всего виртуалки делаю с LVM. Это добавляет некоторые удобства, которые по сути ничего не стоят. То есть не вижу смысла их не использовать. Хоть и не часто, но LVM может сильно выручить.

Например, была виртуалка с большим разделом под хранилище. Покупалось всё с запасом, но через несколько лет место всё равно закончилось. В сервере были свободные слоты под диски. Добавили пару дисков, сделали RAID1, подключили его к виртуалке и расширили раздел с данными. Никаких рискованных движений, никаких переносов данных, даже перезапуск виртуалки не понадобился. Всё сделали наживую.

Расскажу про ещё одну фичу LVM, которую легко использовать, и которая в некоторых ситуациях может серьезно выручить. Речь пойдёт про снепшоты. Именно снепшот LVM спас Gitlab во время эпической аварии, когда они могли потерять все данные, но между делом сделанный снепшот их спас.

Снепшоты могут выручить, если у вас хранилище гипервизора без их поддержки, что не так уж редко бывает. Например, хранилище в Proxmox типа LVM, не LVMThin, снепшоты не поддерживает. Также актуально, если вы арендуете VPS без доступа к гипервизору. Обычно там можно только расширить диск, что достаточно для использования снепшотов.

Для того, чтобы использовать снепшоты LVM никаких настроек делать не надо. Главное условие – в VG должно быть свободное место. Если его нет, то надо его где-то найти. Покажу на конкретном примере.

Беру виртуалку, которая полностью установлена на LVM, что я чаще всего и делаю. На VG свободного места нет. Проверяем это:

# pvs

Добавляем в виртуальную машину ещё один диск, либо расширяем существующий. Принципиальной разницы нет. У вас либо появится новый диск, либо новый раздел на текущем диске. Их и используем для расширения VG. Я добавил диск sdb размером 10G. Расширяю им VG:

# vgextend vgroup /dev/sdb

По хорошему лучше сначала сделать раздел sdb1, и расширить уже им, но для краткости опускаю этот момент.

# pvs
PV      VG   Fmt Attr PSize   PFree  
/dev/sda1 vgroup lvm2 a-- <20.00g   0 
/dev/sdb  vgroup lvm2 a-- <10.00g <10.00g

Теперь могу создать снепшот корня. Делаю ему размер 9G:

# lvcreate -L 9G -s -n root_snap /dev/vgroup/root

Смотрю, что получилось:

# lvs

По сути появился ещё один LV. С ним можно работать, как с обычным разделом. Например, подмонтировать его:

# mount /dev/vgroup/root_snap /mnt

Увидим в /mnt состояние системы на момент создания снепшота.

Посмотрим, как снепшот работает. Полностью обновим систему и перезагрузимся:

# apt update && apt upgrade -y && reboot

После перезагрузки посмотрим на статус LV и на версию загруженного ядра:

# lvs
root    vgroup owi-aos--- <20.00g                           
root_snap vgroup swi-a-s---  9.00g   root  15.85   

# uname -a

Допустим, что-то пошло не так и нам надо откатиться на состояние до обновления. Восстанавливаем снепшот:

# lvconvert --merge /dev/vgroup/root_snap

Видим ошибку:

Delaying merge since origin is open.
Merging of snapshot vgroup/root_snap will occur on next activation of vgroup/root.

Это нормально, так как для восстановления нужно размонтировать LV. Наживую восстановить снепшот нельзя. Восстановление будет запущено после перезагрузки, во время активации LV. Текущий корневой LV будет помечен как (O)rigin with merging snapshot, это видно в lvs:

# lvs
root vgroup Owi-aos--- <20.00g

После первой перезагрузки начнётся восстановление из снепшота. Так как это корневой раздел, полностью всё перезаписать не получится, так как раздел системный, файлы заняты рабочими процессами. Делаем reboot ещё раз. После него система вернётся в состояние до снепшота. Можно проверить это по загруженному ядру:

# uname -a

Для несистемного раздела всё выполняется без перезагрузок. В случае, если всё ОК и снепшот не пригодился, удаляем его:

# lvremove /dev/vgroup/root_snap

💥 Обязательно удалите снепшот после того, как убедитесь, что он не нужен.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#lvm

Продолжу вчерашнюю тему со снепшотами LVM, так как в публикации не хватило лимита по объёму. Работать со снепшотами можно как с обычными разделами. Его можно монтировать, сохранять в образ и передавать куда-то по сети. Либо без сохранения сразу по сети передать напрямую.

Допустим, вы сделали снепшот /dev/vgroup/root_snap. Можете его сразу передать на другой сервер:

# dd if=/dev/vgroup/root_snap | ssh root@10.20.1.36 "dd of=vgroup-root.img"

Получили живой бэкап. Его можно, к примеру, подмонтировать и посмотреть данные:

# mount vgroup-root.img /mnt

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

# dd if=/dev/vgroup/root_snap of=/mnt/backup/vgroup-root.img

Из этого снимка можно восстановить систему полностью. Для этого нужен будет какой-то загрузочный диск c Linux. Нужно будет восстановить данные из образа на какой-то диск и отдельно установить на него загрузчик grub. То есть это простой и гарантированный способ получить целостную копию работающей системы и спокойно передать её куда-то по сети.

☝️ Отмечу ещё раз отдельно, что снепшоты LVM – вполне стабильная и рабочая функциональность. Это не какой-то хак, трюк, костыль, который работает на свой страх и риск. Можно без особых опасений её использовать, главное понимать нюансы работы снепшотов. Они немного снижают производительность, их нельзя оставлять надолго, так как они начинают занимать место в VG, которое может кончиться. Могут возникнуть проблемы.

Снепшот делается по ситуации, проверяется работа после его создания. Потом он либо куда-то сохраняется, либо откатывается, либо сливается с текущим состоянием. Оставлять его не нужно. Слияние большого снепшота, особенно на нагруженной системе, может прилично нагрузить дисковую подсистему.

Вот ещё одно коротенькое руководство, как можно с помощью снепшотов безопасно обновить систему, которая установлена в VG vgroup на LV root.

Переименовываем текущий LV и создаём вместо него snapshot с таким же названием:

# lvrename vgroup root root-old
# lvcreate -n root -s /dev/vgroup/root-old -L 9G
# reboot

Перезагружаемся. Теперь у нас снепшот в роли корневого раздела. Мы можем выполнять какие-то действия с системой - обновлять, ломать, тестировать какую-то функциональность. Когда закончите, можно зафиксировать это. Переименовываем текущее состояние в виде снепшота в новое, а корень возвращаем обратно, как было:

 # lvrename vgroup root root-new
 # lvrename vgroup root-old root

Если изменения вам подошли и вы готовы их принять, то сливаем снепшот нового состояния с текущем корнем:

# lvconvert --merge /dev/vgroup/root-new
# reboot

После перезагрузки по lvs смотрим, когда слияние закончится и перезагружаемся ещё раз:

# lvs
# reboot

Чтобы все изменения применились, надо перезагрузиться 2 раза. Снепшот при слиянии удаляется автоматически, ничего для этого делать не надо.

Если же вам изменения не нужны, то просто удаляем снепшот:

# lvremove /dev/vgroup/root-new
# reboot

Инструкция 100% рабочая. Проверял несколько раз и на прошлой заметке, и на этой. Снепшоты, когда вся система вместе с /boot разделом на LVM работают без проблем.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#lvm

🎓 Известный титулованный питерский институт ИТМО, который готовит ИТ специалистов, выкладывает в сеть много обучающего материала. Точнее не он, а его лекторы на неофициальных каналах. Я как минимум 2 нашёл, где выложены полноценные академические лекции для студентов. К некоторым даже конспекты есть.

В уникальное время мы живём. Все знания доступны. Бери и пользуйся. Никакой сакрализации научных знаний. Каждому доступно университетское образование, причём на всех языках мира.

Я нашёл как минимум 2 насыщенных лекциями преподавателей ИТМО youtube канала. Сразу дам ссылки на конкретные курсы лекций:

Записи курса компьютерных сетей, который читается для студентов третьего года обучения программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в шестом семестре.
Лектор: Сергей Мельников
▶️ [s6 | 2023] Компьютерные сети
✍️ Конспект лекций

Лекции Артема Береснева по курсу Компьютерные сети в университете ИТМО
▶️ Лекции по курсу Компьютерные сети

Живая, аудиторная запись. Звук не очень, но атмосферу передает.
▶️ Администрирование Windows Server

Полный курс из 15-ти лекций по администрированию GNU/Linux
▶️ Администрирование в ОС GNU/Linux

Записи лекций по курсу «Разработка на Go», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в качестве курса по выбору.
Лектор: Панасюк И.А.
▶️ [SC | 2024] Разработка на Go

Записи лекций по курсу «Операционные системы», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: А. В. Маятин
▶️ [s3 | 2024] Операционные системы (light)

Записи лекций по курсу «Операционные системы (hard)», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: А. В. Романовский
▶️ [s3 | 2024] Операционные системы (hard) - лекции

Записи лекций по курсу «Операционные системы (hard) — практики», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: Никита Сычев
▶️ Операционные системы (hard) - практики

Стало интересно, что это вообще за институт. Посмотрел образовательные программы и программы обучения. Всё самое современное, типа DevOps в разработке и управлении информационными системами. Вспоминаю, как я учился в начале 2000-х и что тогда проходили в вузах. По IT вообще ничего актуального не было. Все в основном учились где и как попало, а потом сами всё изучали на работе. Я учился в МИРЭА на бюджете и потом в РосНОУ платно. Как хорошо, что я ушёл из МИРЭА. Там вообще ничего востребованного не преподавали в то время. В РосНОУ хоть что-то похожее на актуальные знания были: программирование, в том числе C++, Java, системное администрирование, операционные системы. Институт был новый, более-менее современный на тот момент.

Другое дело, что в том же ИТМО всё в основном платное. В среднем 450-550 т.р. за год. Дорого, конечно, но не запредельно, если у тебя мало детей. А если как у меня 4-ро, то денег для всех на такое обучение скорее всего не будет. Пока не знаю, как буду выкручиваться.

Мне интересно, есть примеры людей, которые не получили высшее образование, но учились по подобным лекциям в интернете? Они вообще хоть кем-нибудь изучаются или выкладываются в основном чтобы были?

#обучение