нужен *nix администратор в крупную компанию

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

while read h tmp; do ssh $h uptime; done < file.txt

Зачем нужен tmp догадайтесь сами.

Надо иметь привычку писать максимально «живучие» скрипты. На мой взгляд, именно это и есть Unix стиль мышления, о котором писал автор ветки.

Хотя в busybox конечно может быть встроен и cat, и xargs, но если наш скрипт не только для embedded систем, то лучше всего конечно обходиться возможностями bash. Но чаще даже не bash, а sh (bourne просто, не again). Многие не представляют как много умеет sh. Никакие sed-ы, awk и grep-ы не нужны.

Немножко подскажу:

Видете ли... В сервере 2 интерфейса. Для приватных сетей и для внешних. Добавить больше физически невозможно.

Далее, проблема в том, что tcp_outgoing_address в кальмаре отказывается работать с алиасными IPшниками. По крайней мере, в моих кривых ручонках. Впрочем, в гугле у народа та же проблема. Точнее, он даже запускается и даже не ругается. Но какой бы tcp_outgoing_address IP-адрес из внешней подсети алиасом ни указать, реальный траффик будет идти через тот интерфейс, через который прописан default gw. Ну и с тем же source IP, ессно.

Вот и приплясали к тому, с чего начали... :)

Каноничный вариант:

u='root'
while read h; do
    ssh -n ${u}@${h} 'uptime'
done < file.txt

Но иногда без старого доброго expect с spawn ssh не обойтись, например если ключей нет.

Видете ли... В сервере 2 интерфейса. Для приватных сетей и для внешних. Добавить больше физически невозможно.

И не надо.

Далее, проблема в том, что tcp_outgoing_address в кальмаре отказывается работать с алиасными IPшниками

Ну я же назвал, во-первых, сразу два направления именно на этот случай: второй - виртуалки. Сделать десятка два-три-четыре OpenVZ-контейнеров для отдельно взятых сквидов не проблема. Во-вторых, на Squid свет клином, возможно, не сошёлся. Направление без Squid исследовалось ?

Ммм... Вот всегда и всем говорю: виртуалки - зло. Большего идиотизма и придумать-то сложно: зачем тратить вычислительные ресурсы на эмуляцию/виртуализацию, когда их можно успешно потратить непосредственно на поставленную задачу? :) Нет, виртуалки не используются и не нужны. Равно как, даже, не нужно более одного инстанса кальмара. :)

Пробовал TPROXY в кальмаре. Не заработало. :) Вернулся на решение с использованием кальмара и прозрачным проксированием через REDIRECT/DNAT.

зачем тратить вычислительные ресурсы на эмуляцию/виртуализацию

Они почти не тратятся в случае OpenVZ.

Вернулся на решение с использованием кальмара и прозрачным проксированием через REDIRECT/DNAT.

А какое отношение REDIRECT и DNAT имеют к запросам, которые уходят от Squid наружу ? Куда оно редиректится-то ?

А какое отношение REDIRECT и DNAT имеют к запросам, которые уходят от Squid наружу ? Куда оно редиректится-то ?

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

Ммм... Вот всегда и всем говорю: виртуалки - зло. Большего идиотизма и придумать-то сложно: зачем тратить вычислительные ресурсы на эмуляцию/виртуализацию, когда их можно успешно потратить непосредственно на поставленную задачу? :)

Что за бред?

Бред написан в предыдущем посте.

А вы вообще представляете, как работает кальмар в режиме прозрачного прокси? Ну хотя бы погуглите, что ли...

Больше скажу, даже знаю. :-)

Только ваш вопрос был про тот IP, от которого работает прокси с внешним миром, а rediret или dnat используется для перенаправления трафика _на_ него. Того, который _изнутри_. Как вы используете redirect для организации запросов _наружу_ _от_ squid, для меня загадка.

Так и TPROXY тоже используется для перенаправления изнутри на кальмара. О чем и речь, в общем-то... :) Вы просто поняли то, что захотели понять. Редирект/ДНАТ, конечно, не используется для наружного выхлопа.

P. S. Я уже подсказал ну просто всё, что только мог. ЛОЛ.

5го и 6го человека. Маньяков

О, я как раз недавно в новостях про маньяка и 6 человек в офисе слышал. Правда он юристом был, а не линуксойдом.

А вы вообще представляете, как работает кальмар

А, на самом деле, всё ещё смешнее. Если погуглить банальное
squid src ip for outgoing reqest, можно сразу нагуглить какой-нибудь

http://linuxaria.com/pills/setup-squid-to-use-multiple-outgoing-ip-addresses?...

Так что, изначальный вопрос вообще не проблема, получается.

Это для кальмара, работающего в режиме обычного прокси. С прозрачным не прокатит.

Это для кальмара, работающего в режиме обычного прокси. С прозрачным не прокатит.

Это вот точно не проблема. Непрозрачный может быть сиблингом для прозрачного.

Это, как раз, главнейшая проблема. Как я писал выше, tcp_outgoing_address на алиасные IP не работает как нужно. А в этой хаутушке как раз тема про явные алиасы... :(

Честно: решение _без_ алиасов. И вообще, мне почему-то кажется, что вам как-то нехватает кругозора.

Так и TPROXY тоже используется для перенаправления изнутри на кальмара. О чем и речь, в общем-то... :)
Вы просто поняли то, что захотели понять. Редирект/ДНАТ, конечно, не используется для наружного выхлопа.

Перечитайте свой исходный вопрос. Там явно написано, что проблема в том, что с одного IP получается слишком много запросов на какие-то внешние ресурсы. А в решении упоминаете огранизацию прозрачного проксирования, как такового, а не решение по разделению запросов по разным IP.

В общем, ваш способ не назван до сих пор, кроме того факта, что вы это решили, всё же, сквидом.

Сдаетесь?

Сложная задача? Справляется 1 человек из 10-15 в лучшем случае.

facepalm

неужто всё ТАК плохо?!

И вообще, мне почему-то кажется, что вам как-то нехватает кругозора.

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

Кстати, про алиасы. А не приходила мысль насоздавать 802.1q интерфейсов с /32 из имеющегося диапазона ? Я бы попробовал, вдруг прокатит...

Сдаетесь ?

Вообще, давно сдался. Свой вариант предложил. Если у вас лучше - назовите. Если нет, можете пользоваться моим. :)

На абсолютное знание squid я не претендую ни в коем случае.

двойной facepalm

while read HOST; do ssh $HOST uptime; done < file.txt

Всё-таки, я наподсказывал слишком много. :) Ну да ладно. Так даже интереснее. Правильной дорогой идете. :)

насоздавать 802.1q интерфейсов с /32 из имеющегося диапазона

Это как? /31 я бы еще понял. Линукс - может быть, тоже. Кошка на другом конце - не факт. Да еще и роутинг через P-t-P городить...

Вот насоздавали вы /30 виланов. И даже tcp_outgoing_address написали из разных подсетей. Запускаете кальмара, а это чудо всё так же шлёт траф через интерфейс с дефолт рутером... :)

Как я писал выше, tcp_outgoing_address на алиасные IP не работает как нужно. А в этой хаутушке как раз тема про явные алиасы... :(

Вообще, вот тут http://www.squid-cache.org/Doc/config/tcp_outgoing_address/ тоже про явные алиасы 10.0.0.1 10.0.0.2 10.0.0.3. Оно точно не работает ?

акой вариант будет работать? Если нет, то почему?

с user будет, с ${user} нет. Болезненная любовь к кошкам тебя сгубила (:

Оно точно не работает ?

Оно, может, работает. Но для явного указания прокси в браузере. В прозрачном - точно не работает.

Это как? /31 я бы еще понял.

Легко. :-) Попробуйте, всё получится.

Кошка на другом конце - не факт.

Ей не надо про это знать. Допустим, у вас сеть /30 для канала и сеть /29 ещё. /29 роутится кошкой через ip из /30 а на сервере /29 бьётся на кучку /32.

а это чудо всё так же шлёт траф через интерфейс с дефолт рутером... :)

Ну это уж вопрос к сквиду, если у него tcp_outgoing_address не работает совсем.

Кошка на другом конце - не факт.

Кошка, кстати, ваша, или оператора ? Если ваша, то можно кваггу поставить и ospf с кошкой сделать, маршруты на /32 сами разойдутся.

/29 роутится кошкой через ip из /30 а на сервере /29 бьётся на кучку /32.

А вы не думали, что на свете вы далеко не один? И что желаемые виланы могут использоваться еще кем-то? :) Так что /30+вилан централизованно выданные. :)

у него tcp_outgoing_address не работает совсем

В том-то и дело, что работает. Но очень капризно.

Ладно. Скоро баиньки. Потому расскажу. Йорик был абсолютно прав, когда написал: «набор технологий и методов которые нужно свести в кучу для получения результата».

Действительно, кальмар работает только для «интерфейсов», но не для алиасов. Алиасы не расцениваются как интерфейсы (кстати, не только сквидом). А вот виланы - для линукса - есть интерфейсы.

Как я уже написал, вам нехватает кругозора. Хотя с виланами вы исправились, про policy routing то ли не знаете, то ли забыли... Вот вы получили «белые» /30 виланы. У каждого есть рутер в дальнейший Инет. Но линукс-то «по умолчанию» знает только ОДИН дефолт рутер! На самом деле, их может быть сколько угодно. :) Достаточно научиться использовать iproute2.

Что-нибудь в стиле:

echo «50 vlan50» >> /etc/iproute2/rt_tables

echo «51 vlan51» >> /etc/iproute2/rt_tables

ip rule add from IP_vlan50 table vlan50

ip rule add from IP_vlan51 table vlan51

ip rule add from 192.168.1.0/24 table vlan50

ip rule add from 192.168.2.0/24 table vlan51

ip route add default via IP_router50 dev eth0.50 table vlan50

ip route add default via IP_router51 dev eth0.51 table vlan51

В принципе, полиси роутинг уже заработал.

Кальмару по аклам:

tcp_outgoing_address IP_vlan50 vlan50

tcp_outgoing_address IP_vlan51 vlan51

Обнулить все rp_filer и нарисовать единичку в ip_forward. Не забыть разрешить форвардинг между интерфейсами.

Ессно, нарисовать в iptables прероутинг с редиректом/днатом и построутинг с маскарадом по -o eth0.5X. Не забыть зарубить петли в iptables.

Ну дальше дело техники и мучений с тестами. :) Кальмар - капризная штука и на неправильные записи в iptables обижается. :)

И никакие виртуалки/дополнительные инстансы не нужны.

А вы не думали, что на свете вы далеко не один? И что желаемые виланы могут использоваться еще кем-то? :)

Нет. Они не могут использоваться кем-то ещё, так как оператор дал вам один. Или не дал вообще, а порт на его стороне в untagged (access, словами циски). То, что вы локально на сервере насоздавали VLAN, касается тлько вас (если оператор вменяемый; хотя, на самом деле, правильно это не на провайдерском интерфейсе сделать, а на своём - в моём варианте это по баратану, можно и не на ethernet интерфейсов наделать).

Алиасы не расцениваются как интерфейсы (кстати, не только сквидом). А вот виланы - для линукса - есть интерфейсы.

Вообще, не надо мне очевидных вещей рассказывать, я, может, тут чуток поболее знаю. ;-)

Вот вы получили «белые» /30 виланы. У каждого есть рутер в дальнейший Инет.

Я исхожу из того, что вам не дали такого счастья. Я бы (и да, я - представитель оператора, на всякий случай ;-) ) не дал, если бы вы мне вразумительно не рассказали, зачем вам столько интерфейсов в разных vlan. Пока я не уверен в том, что вы правы и нет другого решения.

Про полиси роутинг, rp-filter и т.п. рассказывать мне тоже не надо, это всё очевидные вещи.

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

Хех. «Каждый может». Проблема в том, что за без малого полсуток вы этого предложения так и не сделали.

А теперь пишете, что «очевидно» и «не интересно».

Ладно, спокойной ночи. Ушел баиньки.

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

Так не было соответствующей вводной. :-) И, плюс, я считаю, что это чрезмерный огород. Даже вариант с виртуалками на порядок лучше этого. В общем, я бы ваше предложение, при приёме на работу, может быть, и зачёл, так как определённый обём знаний вы имеете, но вот использовать это... Не знаю.

Но линукс-то «по умолчанию» знает только ОДИН дефолт рутер!

Кстати, Linux умеет ecmp. По крайней мере, вместе с кваггой.
Но не знаю, как к этому отнесётся сквид...

Так не было соответствующей вводной. :-)

Так и у меня её не было. А вот желание найти решение - было.

это чрезмерный огород
вариант с виртуалками на порядок лучше этого
я бы ваше предложение...

А я бы ваше - нет. Ибо мыслите вы штампами, суете виртуалки куда не следует, воли к решению проблемы не имеете. Следовательно, при сколько-нибудь серьёзной задаче, искать решение пришлось бы мне. А зачем мне работать за вас? :)

Так и у меня её не было. А вот желание найти решение - было.

Обычный клиент не получит десяток VLAN от оператора в одном канале. Потому этот момент нуждается в уточнении.

Ибо мыслите вы штампами, суете виртуалки куда не следует, воли к решению проблемы не имеете.

Вы, очевидно, не знаете, как работает OpenVZ, потому считаете, что это чрезмерный вариант. Что касается воли к решению, у меня, на всякий случай, есть, что решать, потому угадывать ваши условия не сильно было нужно. :-)

Следовательно, при сколько-нибудь серьёзной задаче, искать решение пришлось бы мне.

Ну вот я и говорю. Ваше решение очень далеко от идеала. Первое пришедшее в голову, можно сказать, исходя из возможностей наведения любого бардака в сетевой инфраструктуре. Если всё проверить до конца, не исключено, что оно может оказаться единственным, но Вы, явно, не закончили со Squid, а пошли по лёгкому пути. Может быть, как-нибудь, когда будет скучно на выходных, я проверю, что у Вас не получилось с tcp_outgoing_address.

Для данной мега-задачи есть dsh вообще-то...
Что-то вроде dsh -f $pthHostsList uptime.
xargs'ом вообще никогда не пользуюсь: наЗАЧЕМ, если можно тоже самое сделать встроенными средствами языка? А потом BASH обвиняют в том, что он-де медленный . Да куда ж ему не быть таковым, если вы по каждому поводу, а чаще без, делаете exec'и с подгрузкой бинарников, иногда в сотни килобайт весом, а иногда и в тысячи (особенно доставляет вызов perl'а из BASH'а - вообще больные люди такое могут только практиковать).

Хорошо, давайте говорить по знаниям. Вот мой вариант задачки:

pssh -h file.txt -o uptimes.txt uptime

В результате отчет по аптаймам будет в файле, который потом удобно обработать.

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

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

Могу эскалировать сервисы в случае падения тазиков

Что вы, простите, можете делать с сервисами?
Когда говорят «эскалировать проблему» - тут понятно, что калька с английского языка: обострение, передача проблемы для решения на более высокий уровень (например, с привлечением следующего уровня техподдержки или доведением до сведения руководства).
А эскалировать сервис - это вообще как?
Работал с Veritas Cluster Server и SUN Cluster, но не слышал употребления данного выражения в контексте HA-кластеров.

Может быть вы слышали «миграция»? Ну так это тоже самое.