Все такие умные и опытные, что под столом валяются, вспомните себя и свой первый опыт с FreeBSD. Заходишь на форум в USA на вопрос - получаешь ответ, ну или уточняющий вопрос, у нас же в лучшем случае узнаешь, что ты тупой мудак, сорри. Никогда таких вопросов не задаете? - Откройте свои сообщения 10 летней давности на форумах. Как по мне вопрос вполне нормальный, для не имеющего опыта с фрей, скрины есть (или как Вы их предлагаете делать с локальной консоли?). Автору топика, если еще не побороли - кидайте ssh в личку или скайп - полечу, там делов на 5 минут.

тобто запустивши в мережі на клієнтському ПК можна навмисне порубати всім доступ до інтернету?
як захиститись подібного рейду?

Строить сеть на нормальном железе. Сеть на мыльницах можно положить тупо замкнув на стороне абонента нужные пары на патчкорде, проще, быстрее и эффективней.

R.I.P. Покойся с миром, ты навсегда останешься в наших сетях сердцах.

кстати да, во фре хоум линкуется.

а вот команда чисто линуксовая
du -h --max-depth=1

во фре надо так
du -hd 1

Rico-X, если он на ходу слайсы перебивал и перемонтировал, то врядли бы задавался таким вопросами про место ))

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

ага, ну может еще в /etc/ и /home

Это врядли, в /etc хранятся только текстовые конфиги и надо постараться, чтоб он разжирел, а /home вообще по дефолту примонтирован как /usr/home , а /home симлинк на /usr/home

в root ?

du -h --max-depth=1 в корне, глянуть что за каталог самый жирный, создать на другом слайсе, где много места, каталог, скопировать туда все содержимое жирного каталога, удалить жирный каталог и создать симлинк на каталог на другом слайсе. (Лучше делать с live CD) а еще лучше вместо симлинка создать новый слайс, указать его точкой монтирования жирный каталог, а мусор с жирного каталога перекинуть на новый слайс. И самый правильный вариант сделать дамп разделов, форматнуть диск, разметить заново и сделать рестор слитого ранее дампа, вот вам 3 решения на выбор.

У Вас в каждом свиче по бизнес-партнеру и крупному клиенту? Апдейт большого количества коммутаторов иногда необходим для функционала, как пример обновлял Dell 34xx серии, в сети сначала небыло мультикаста, потом появился, встала необходимость использовать ip igmp snooping, в той прошивке что была на коммутаторах его поддержки небыло, в крайней была, но требовалось не только обновление прошивки но и бутрума, так что да более 100 коммутаторов обновлял и бутрум и прошивку скриптом за 1 раз, потом этим же скриптом проверял что коммутатор поднялся, включал новую функцию, проверял работу и переходил к следующему, в условии скрипта было остановиться и проорать алярму, если хоть одна проверка работоспособности не прошла, скрипт работал почти 6 часов, ручками - это месяц работы.  Простой каждого коммутатора около 4 минут, руками всегда дольше, да я за автоматизацию где это возможно. Второй случай массового обновления, закрытие критичной дыры в комутаторах линксис, ждать скрипткиди - спасибо, уж лучше планово постоять пару минут. Разрешение от всех инстанций никто не получает, предварительно за неделю всем по рассылке отсылается предупреждение о плановых работах в сети с временем проведения и конечными сроками устранения, все крупные бизнес-клиенты имеют минимум 2 аплинка так что на время работ просто переходят на резерв, если у такого клиента не предусмотрена ситуация выхода из строя основного аплинка (по любой причине) то он сам себе злобный буратина. А то у вас получается ситуация "Солидная компания возьмет в аренду дырокол".

Вы на стенде будете симулировать все возможные варианты настроек свичей в сети? Я мимо стенда тоже не обновляю ничего, но прошиваю все свичи ручками с обязательной проверкой после

Завидую вам, у вас огромное количество свободного времени. Я вот шью и настраиваю все скопом и мне даже в страшном сне не упало ручками шить или настраивать больше 300 свичей  (сеть гетерогенная 4 вендора, определение вендора в скрипте по SNMP). Запустил сразу на сегменте 10 штук и географически рядом с техплощадкой, если все ОК - на всю сеть, за все время от такой операции померло аж 2 свича (оба по умирающему флеш) что даже хорошо, сразу заменили в спокойной обстановке на нормальные, те в ремонт. Просто такая операция делается не когда левая пятка зачешется, а назначается день профилактических работ, монтажники готовы, абоненты предупреждены через объявление на сайте. Делается порайонно, совместно с другими операциями в сети. Хороший админ - ленивый админ, вряд ли вам платят зарплату за тупую механическую работу. Полностью согласен с ser970 в этом вопросе.

[cat auto-switch.sh]

Для телнета можно 2мя скриптами примерно такого плана.
Скрипт номер 1, которому на вход первым аргументом передаем текстовый файлик, где каждая строка ip свича, можно переделать под простой перебор в диапазоне:
cat auto-switch.sh

Код:

#!/bin/bash
FILE=`cat $1 | sort -u` 
for I in $FILE
  do
 if [ -n "$I" ]
  then
./auto-dell34XX.except $I
fi
done

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

Скрипт номер 2, вызывается скриптом номер 1, строкой ./auto-dell34XX.except $I

Код:

#!/usr/bin/expect -f
set SWITCH_IP [lindex $argv 0]
log_user 1
spawn telnet $SWITCH_IP
send "admin\r"
expect "Password:" {send "Логин\r"}
expect ">" {send "enable\r"}
expect "Password:" {send "Пароль\r"}
expect "#" {send "conf\r"}
send "Команды, необходимые для перепрошивки"
send "Каждая в новой строке"
expect eof

Команда send просто посылает на ввод строку, команда expect сначала ждет на выводе подстроку, а только потом посылает команду.

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

3 она в свою очередь виснет на стадии загрузки)

вот у меня и виснет она на стадии загрузки

Там нужно пробовать с разными типами HDD и виртуализации на каком-то у меня тоже висла, если совсем туго, могу собрать образ для KVM и выложить.

Все завиртуалил кроме сателитов freebsd
причина
1 чтобы рулить большой поток трафика надо virtio драйвера
2 они есть только под freebsd am64 которая
3 она в свою очередь виснет на стадии загрузки)

Может кто поборол ?

http://pve.proxmox.com/wiki/FreeBSD_Guest_Notes У меня под proxmox полет нормальный, правда большой нагрузки нет - тестовая машина, но фря как и другие виртуалки работает ровно.

Ну раз такое дело вариант балансировки нагрузки на pf излеченный от болезни когда часть сайтов не пашет.

Код:

set limit states 128000
set optimization aggressive
ext_if1="vlan100" #Kanal1
ext_if2="vlan200" #Kanal2
ext_gw1="192.168.88.1"
ext_gw2="192.168.89.1"

table <no_nat> const { 192.168.0.0/16 10.0.0.0/8 }
scrub in all #Lechim trafik

nat on $ext_if1 from 10.0.0.0/8 to !<no_nat> -> { ($ext_if2) ($ext_if1) ($ext_if2) } round-robin sticky-address

pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to !<no_nat>
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to !<no_nat>

Каналы не симметричны, по этому { ($ext_if2) ($ext_if1) ($ext_if2) } для симметричных лучше  так { ($ext_if1) ($ext_if2) }

На что только люди не идут, чтоб динамическую маршрутизацию не пилить.

Локальные на разных техплощадках.