Нет, аналоговой телефонии у нас не было, только IP.
В линуксе есть свои прибабахи, просто в других местах. С теми же дровами и т. п.
Правда считаете, что если вы не разобрались, как проходит ESP пакет по стеку, то это проблема BSD? :-) Во фре очень отзывчивое сообщество. В трудных случаях я писал прямо разработчикам, и они довольно быстро отвечали. Возможно, стоило к кому-нибудь обратиться?
Вы всерьез собираетесь обьяснять руководству, что вот мы берем это, а не то только потому что оно работает под FreeBSD? Добро, если цена примерно одинакова, а если нет?
Вы в каком-то причудливом мире живёте. В котором железо не подбирается под задачу. Почему-то для организации кластера VMware + vSAN следовать HCL -- это норм, а при выборе FreeBSD в качестве основной ОС HCL соблюдать -- уже западло? Любая ОС имеет свои ограничения по железу. Где-то больше, где-то меньше. Но они есть всегда.
Винда прекрасна тем, что работает из коробки. И проблем с драйверами действительно куда меньше. Т. к. каждый производитель разрабатывает драйвера под Windows, и сильно не каждый даёт таковые под Linux.
Я пользуюсь виндой уже около 20 лет, начиная с Windows NT4. И виснет она только при наличии проблем на железе.
А в линуксе для того, чтобы запустить всё набортное оборудование, придётся сначала изрядно посношаться. Так что тут ещё большой вопрос, что из двух ОС шашечки, а что -- ехать.
Кстатие, в макоси юзер куда как бесправнее, чем в винде. И ничего, хавают, и ещё нахваливать умудряются :-)
sim3x, у него весь сервер подконтролен, он и так может сделать что угодно. Поэтому внешний контроль сети -- должен быть. А модемов бояться -- в ДЦ не ходить.
Сайпутдин Омаров, это дело хозяйское. Знание, как конфигурировать коммутаторы через expect вам вряд ли где-то пригодятся, а ansible -- промышленное решение.
Сайпутдин Омаров, товарищ stratosmi бредит, не обращайте внимания. У ansible есть модули работы с оборудованием Cisco. Никакая установка питона на коммутаторы для этого, разумеется, не требуется.
t38c3j, /etc/crypttab проверьте. Если там есть какие-то отсылки на криптоконтейнеры, закомментируйте их и грузитесь. Похоже, у вас были какие-то криптоконтейнеры, которые система пытается подцепить при загрузке.
И в /etc/fstab тоже закомментируйте строчки, которые отвечают за монтирование зашифрованных файловых систем.
Ростелеку вряд ли DHCP-сервер на клиентском порту проблему создаст. Как правило, у них на доступе достаточно серьёзные железки стоят, которые умеют в DHCP snooping. Разве что купили сеть мелкого провайдера, и ещё порядок не навели.
Fitrager, вланы от загрузки интерфейсов вас не спасут. Точка. Если вы полагаете, что сделав на одном 1G порту два влана, вы сможете заливать туда два гигабита, то нет, так это не работает. Если вы в одном влане вольёте гигабит, то на остальные вланы уже пропускной способности не останется. Поэтому трафик бэкапов будет точно также влиять на пропускную способность сети, как и ранее, независимо от того, изолируете вы его в отдельный влан или нет.
Сеть делится на вланы для двух целей:
1) Уменьшить broadcast-домен и немного снизить долю широковещательного трафика;
2) Увеличение степени контроля за сетью, что ведёт к повышению безопасности.
PlugIN, разработка -- может вестись удалённо. Образование -- нет. Очное общение с группой товарищей, квалификация которых гораздо выше не может быть заменено никаким гуглением или удалёнкой.
Постоянно на связи с джуном, работающим по удалёнке, находиться никто не будет. ВОзможно, и есть такие команды, где такое возможно, но скорее всего будет ровно наоборот -- на удалённого джуна будут все забивать, т. к. забот и так полон рот. Если в офисе можно кого-нибудь поймать за пуговицу и задать вопросы, то по удалёнке это сделать будет куда как сложнее. Почту и мессенджеры будут игнорить, на телефон отвечать через два раза на третий.
sorry_i_noob, но если серьёзно, то в винде тоже есть утилиты командной строки, позволяющие задавать разрешения на файлы. Только вот с утилитами, распознающими формат файла под виндой я незнаком, поэтому ничего не посоветую. Возможно, есть кросс-платформенные либы для PHP, которые это делают. В linux/BSD есть утилита file, а что под виндой -- я даже не знаю.
MakNait, в вашем случае 4 раза NAT проблем особо создавать не будет, но в целом -- это сложная схема и дополнительные задержки при обработке трафика.И ещё, если где-то что-то отвалится -- будет сложнее дебажить.
Ну и в целом -- надо стараться максимально правильную и корректную архитектуру строить. Чем больше костылей -- тем сложнее дебажить, как я уже говорил, и тем сложнее менять/развивать. А требования к информационным системам постоянно меняются, так что модифицировать какие-то настроки придётся, причём скорее рано, чем поздно.
А вы правила в цепочке FORWARD настраивали? Или iptables -P FORWARD DROP -- это единственное, что относится к форварду? А как оно у вас будет пакеты между интерфейсами перекидывать, если у вас весь форвардинг запрещён? :-)
MakNait, прямо в примере конфига OpenVPN сервера в комментариях довольно подробно расписано, как делаются маршруты per client. Это там где про ccd и клиента с именем "Thelonious".
Вряд ли такое возможно. Обычно один диапазон адресов.
Запросто может быть. У провайдера несколкьо BRAS'ов, какие-то отдают серые IP и делают NAT, какие-то -- отдают белые динамические IP-шники и NAT не делают. Зависит от того, куда клиент попадёт. В случае с подключением по PPPoE, например, клиента примет тот BRAS, который раньше ответит.
В линуксе есть свои прибабахи, просто в других местах. С теми же дровами и т. п.
Правда считаете, что если вы не разобрались, как проходит ESP пакет по стеку, то это проблема BSD? :-) Во фре очень отзывчивое сообщество. В трудных случаях я писал прямо разработчикам, и они довольно быстро отвечали. Возможно, стоило к кому-нибудь обратиться?
Вы в каком-то причудливом мире живёте. В котором железо не подбирается под задачу. Почему-то для организации кластера VMware + vSAN следовать HCL -- это норм, а при выборе FreeBSD в качестве основной ОС HCL соблюдать -- уже западло? Любая ОС имеет свои ограничения по железу. Где-то больше, где-то меньше. Но они есть всегда.