/var/lib/mysql - тут лежат все БД у мускуле, значит сюда монтируем SSD диск. Остальное отдаем под систему 50-60Гб на всякий случай и отдельно ( Именно отдельная партиция ) монтируем большой раздел под сайты - /var/www например. Так как если на сайты закинут слишком много контента и диск переполнится, то сервер целиком не упадет.
fedorchuk: RTM - The also-notify statement is relevant only with master zones and defines one or more IP addresses, and optional port numbers, of servers that will be sent a NOTIFY when the master zone file is reloaded.
Первая опция указывает, которому IP можно сливать AXFR , вторая опция будет пинать слейв на предмет обновления зоны при смене сериала на мастере.
1. Завести зону домена на primary
2. Проверить, разрешен ли AXFR на слейв
3. После изменений в зоне изменить сериал зоны ( увеличить ) и перезагрузить днс сервер ( rndc reload )
Самый первый уровень - физический, то есть без воткнутого кабеля у Вас не будет сети.
Далее - канальный, обеспечение связи между несколькими станциями для обмена пакетами, попробуйте включить кабель в компьютер и другой стороной в колбасу.
Далее - сетевой, общая среда обмена информацией. Грубо - Вы не сможете отправить сообщение, не зная адресата. ( IPv4 )
Далее - транспортный. Прямая связь между двумя системами для передачи информации ( TCP, UDP )
Далее - сеансовый. Две стороны договариваются, каким образом они будут общаться. ( NetBIOS )
Далее - представления. Две стороны договариваются, что вот этот набор данных - это изображение, файл, документ
Далее - Прикладной. Сетевые службы ( HTTP , FTP ).
Любая модель OSI зависит от нижних слоев ( смотрим изображение по ссылке ). То есть если нет будет физического подключения или адреса, то HTTP и FTP работать не будет. NetBIOS как сеансовому уровню нужен транспорт. Смотрим, что он работает через TCP/UDP. Ответ очевиден.
1. Вы не должны отправлять почту на gmail с from ящика gmail
2. Вам нужно в качестве from использовать ящик из домена fedos.top , сейчас стоит mymail@gmail.com , который явно фейлится.