Александр

Нужно показывать код, которым вы гордитесь

Код к резюме никогда не прикрепляют, максимум линки, лучше один линк на профайл на гитхаб

Есть небезопасное обновление днс записей. Это когда любой может обновить днс запись. Настраивается, по-моему, в днс зоне. Делать так не рекомендуется. Лучше перенесите роль дхцп сервера на контроллеры домена.

Убедить. Корпоративных. Пользователей?
Бегите оттуда.

завернуть днс записи о этих ресурсах на локалхост ) уж куда бюджетеее

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

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

Совершенно тихо, тепло уходит прекрасно, пыли нет. Есть немного запаха масла и немного геморроя, при замене комплектующих (вытащить, вымыть, высушить, пересобрать, герметик, утопить).

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

1)раздобыть компьютер с убунтой,
2)остановить ваш сервер,
3)подцепить к компьютеру с убунтой ваши новые диски,
4)компьютер с убунтой подключить к серверу, желательно каналом потолще (две сетевые карты есть? а четыре?)

5) на новых дисках создать RAID средствами mdadm ( и никогда не связываться больше с аппаратным рейдом, если у вас контроллер в единственном экземпляре)

6) при помощи dd и nc скопировать поблочно данные со старого рейда в новый по сети. НЕ ФАЙЛЫ СКОПИРОВАТЬ, а все блоки диска целиком

7) старые диски вынуть и на полку, новые подцепить в режиме jbod. То есть, чтобы контроллер никак не вмешивался в их работу, а просто пропускал их наверх, в ОС

8) mdadm должен увидеть новый массив, pvscan должен увидеть на нем LVM

9) расширяем PV на новый размер

10) расширяем VG

11) расширяем ФС

12) Конец.

ipfw стоит изначально, а большинство не любит лишних телодвижений. В ipfw есть netgraph. На ipfw рассчитаны все доки по FreeBSD. В ipfw есть dummynet.

В общем разница примерно такая же как между tcsh и /bin/sh - оба шеллы, на обоих можно писать, но первый по умолчанию стоит только во FreeBSD и больше нигде, а второй есть всюду и знать его надо, потому что стартовые скрипты все равно на нем...

pf проще.
Лично я работал с ipfw, там то же не сложно, когда задачи типовые.
В pf можно достаточно легко сделать балансировку каналов.
На ipfw балансировку сделать сложнее, но зато можно ее сделать такую какую тебе надо, тогда как в pf можно пользоваться только одним встроенным вариантом.
ipfw - более низкоуровневый инструмент.

Присоединяюсь к предыдущему оратору. Работаю с 500+ коммутаторов, но на каждую новую задачу переписываю скрипты, потому что в каждом конкретном коммутаторе много особенностей. Например где-то нужно enable admin делать, где-то нет. Где-то можно указать vlanid, а где-то нужно именно vlan name.

Пример скрипта на питоне - https://pastebin.com/UKTmQdBz

Задача сугубо узкоспециализированная а значит серебренной пули не будет.
Принцип настройки каждому коммутатора может быть уникальный.
Если таких задач много и часто то проще написать(или заказать чтобы написали) утилитку, по сути в ней не будет ничего сложного принцип будет примерно следующий:
1) Список коммутаторов с парами логин\пасс. Необходимые команды для конкретной модели\производителя коммутатора.
2) Утилитка запускается, цепляется последовательно к каждому коммутатору по telnet\ssh, вписывает необходимые команды для конкретного производителя коммутатора или модели.

Другой вариант что можно подобное сделать и через SNMP, понадобятся MIBы коммутаторов, чтобы они поддерживали SNMP и возможность изменения параметров через него. Дальше дело техники и реализовывать функционал в каком нибудь забиксе или простой скриптик который опять же возьмет список IP коммутаторов и консольными утилитами snmp по конкретным OID'ам сделает изменения.

Я тоже искал с вебкой, так как набирать заклинания, чтобы увидеть простые вещи, мне, как не по себе было. Мой выбор лёг на moosefs, там всё просто и без приключений, конечно есть минусы, но всё можно победить в самом начале. СЕРН она не столько сложная, сколько надо делать много тело движений, но выбор всегда ложиться на админа и, что ему ближе, то и будет работать.

Холиварный вопрос.
Но для начала бы посоветовал debian. Он поприятнее для начала будет. И сам по себе дистрибутив очень стабильный без лишних включенных опций по умолчанию.