2 сервера на freebsd, находятся в одной подсети с маршрутизаторами.
То есть оба адреса 10.141.1.1 и 10.141.100.9 (я ведь правильно понял, это адреса маршрутизаторов?) входят в один префикс (/17 или короче), используемый на L2-домене(линке)?
У каждого из серверов по несколько сетевых адаптеров, "смотрящих" в разные сегменты. Маршрутизатор 10.141.100.9, у серверов адреса 10.141.100.5 и 10.141.100.6 соответственно. Маска 255.255.255.240.
10.141.1.1 - это адрес в другом сегменте, с другой маской. Откуда взялась совершенно бредовая маска /17 я не совсем понял. Разве я такую маску упоминал? Не надо придумывать лишних сложностей.
С одного все данные получаются, с другого - нет. Ограничение стоит на другие сети, в данной подсети ограничений нет, тем более, для одного конкретного хоста.
Вообще-то, как правило, принято (этому способствует логика настройки) разрешать SNMP-доступ для каждого конкретного хоста, а не "ограничивать сети".
Правила, принятые в вашей организации, не являются стандартом де-факто для всех. У нас пулы серверов мониторинга вынесены в отдельные сегменты, отделены файрволом с параноидальными настройками от внешних сетей и от рабочих станций пользователей. Прописывая подсети /27-/29 мы не имеем угроз на данном уровне.
Приведите конфигурацию каждого из маршрутизаторов в части SNMP.
Настройки snmp самые минимальные и тривиальные.
snmp-server community public RO
snmp-server community write RW
Пароли, естественно, другие. Еще стоят правила на файрволе, запрещающиен доступ по этому протоколу извне сети, стоят правила на самом маршрутизаторе, разрешающие обмен всеми пакетами внутри сети, в которой находятся маршрутизаторы. В утрированном виде, это небольшая подсеть, существующая только для обмена транспортными данными между маршрутизаторами. Каждый из серверов имеет по интерфейсу в данном сегменте для мониторинга и интерфейс в другой сегмент для отдачи данных фронт-энд серверам статистики. Конкретные разрешенные или запрещенные адреса на маршрутизаторе прописывать нет нужды, только подсеть.
Мммм, BDSM, DesignOverAnal.... На каждой фотографии фон может отличаться. Где то рисунок занимает весь размер фотографии, где то левое поле больше правого, где то рисунок смещен вниз. Края изображений будут обрезаны. Я уважаю нестандартные решения, но за такое я бы подрядчику руки отрубил бы.
1. Слава богу, у меня без бликов, обычные рисованные элементы с четкими краями.
2. Как сделать в фотошопе я знаю, но обрабатывать тысячи объектов из кучи подпапок - не мое, мне проще пару вечеров на программу потратить. Тем более, я описал идеальный вариант и допустимые. С ними гораздо проще.
3. Блики и пушистости не для идеального варианта, а просто для максимальной обрезки краев, отделяются не просто, а очень просто. Задаем чувствительность, т.е. допустимую погрешность белого. Слева находим самую крайнюю координату, это левое ребро квадрата. Находим самую правую координату изображения. Низ и верх точно так же.
4. Наложение прозрачности при заданной небольшой чувствительности даже на обычных фотках даст менее 1% брака за счет краев и бликов. Вывести все фотки на одну страницу с очень контрастным фоном (ядовито-синий, черный) и глазами отфильтровать брак гораздо проще, чем вручную лопатить тысячи фоток в фотошопе.
5. Про десятилетия работы по смене фона можно чуть подробнее по пруфлинку?
Вы абслютно не правы. Рациональное решение есть и я очень хорошо себе представляю его. На php писал распознавание разных объектов. Ад, но вполне решаемая задачка. Построчно проходим всю картинку и попиксельно сравниваем с заданным цветом + погрешнось 10-15 единиц. Вычисляем максимальные и минимальные координаты (max/min элемены массива) и заменяем их на нужный цвет. Я алгоритм вполне хорошо себе представляю, но это 1-2 полных вечера работы. А я ленив и стараюсь сначала найти готовые решения, чтобы не изобретать велосипед.
К тому времени, как я закончу обрабатывать несколько тысяч картинок, придумают новые форматы изображений, напишут HTML 9.4 и сайт уже никому не нужен будет.
Самое простое? Я уже делал для сайта несколько функций ресайза картинок, конвертации и т.п. Городить с нуля такое я уже не хочу. поэтому ищу готовый вариант.
Добавил установку куков, в которых передавал параметры другим скриптам, и сам через куки получал исходные данные, часть кода вставил непосредственно в обработчик принятых файлов. Через задницу, зато принимает файлы размером в гигабайты.
Есть каталог с большим количеством файлов в подпапках в разных форматах. 3 человека, захотели просмотреть крупную галерею. Сервер начинает "лопатить" сотни файлов, сначала конвертируя в нужный формат, потом еще изменяет размеры. На этом сервер и умрет. Таким веб-мастерам надо руки ломать и сращивать более прямо, чем есть сейчас. У любого программиста, в том числе и веб-мастера, уровень оптимизации продукта должен быть параноидальным. Соответственно, подготовка изображений должна быть предварительной.
Пока ДНС-сервера и само содержимое находятся у хостера. Лишняя работа, лишние деньги, лишние телодвижения. Расширю в следующем году канал на контору, поставлю дополнительные сервера, оба контроллера одной ногой вынесу в DMZ, выбью небольшой пул статических адресов для ДНС и веб-сервера. ДНС-ы будут у меня, веб-сервер будет у меня, все будет красиво. :-)
По поводу сертификатов - это пока не в реальных планах, просто рассматриваю возможность и закладываю заранее возможность.
Я не представляю, что будет в дальнейшем. Поэтому, чтобы не искать проблемы в будущем, решил с "неправильными" доменами типа .local не связываться. Слишком часто приходилось сталкиваться, когда раньше не предусмотренные фичи понадобились, а без глобальных разрушений ввести их нельзя. Поэтому стараюсь максимально все предусмотреть и обезопаситься.
Я в теме, просто не обратил внимания на www. Такая запись в локальном домене не заводилась, т.к. пользователи заходят на сайт по имени COMPANYNAME.ru. Завести для внутренних пользователей A-запись www.COMPANYNAME.ru, которая будет указывать на сервер хостера, я считаю крайне не верным. У него целая ферма серверов, на которых крутятся сотни виртуальных хостов. Завтра сервер умрет или мигрирует на другой айпишник, на ДНС-серверах хостера появится изменение, а у меня перенаправление будет идти на старый айпишник. Через пару лет все забудут об этом костыле и при первой же смене айпишника придется мозг погнуть, пытаясь понять, где же сбой.
Прошу прощения у всех за потраченное время, глупая ситуация получилась. В пятницу старый dir-320 и новый dir-320NRU мучал, менял на обоих несколько прошивок и взял домой dir-320NRU. Сижу и пытаюсь на dir-320NRU накатить прошивку от старого маршрутизатора. Начал фотографировать и только тогда обратил внимание на несоответсвие версий.
Пробовал и так. Подсовывал родную прошивку и dd-wrt: Flashing failed
ERROR - the image you uploaded failed to pass verification.
Please make sure to use an official update.
То есть оба адреса 10.141.1.1 и 10.141.100.9 (я ведь правильно понял, это адреса маршрутизаторов?) входят в один префикс (/17 или короче), используемый на L2-домене(линке)?
У каждого из серверов по несколько сетевых адаптеров, "смотрящих" в разные сегменты. Маршрутизатор 10.141.100.9, у серверов адреса 10.141.100.5 и 10.141.100.6 соответственно. Маска 255.255.255.240.
10.141.1.1 - это адрес в другом сегменте, с другой маской. Откуда взялась совершенно бредовая маска /17 я не совсем понял. Разве я такую маску упоминал? Не надо придумывать лишних сложностей.
С одного все данные получаются, с другого - нет. Ограничение стоит на другие сети, в данной подсети ограничений нет, тем более, для одного конкретного хоста.
Вообще-то, как правило, принято (этому способствует логика настройки) разрешать SNMP-доступ для каждого конкретного хоста, а не "ограничивать сети".
Правила, принятые в вашей организации, не являются стандартом де-факто для всех. У нас пулы серверов мониторинга вынесены в отдельные сегменты, отделены файрволом с параноидальными настройками от внешних сетей и от рабочих станций пользователей. Прописывая подсети /27-/29 мы не имеем угроз на данном уровне.
Приведите конфигурацию каждого из маршрутизаторов в части SNMP.
Настройки snmp самые минимальные и тривиальные.
snmp-server community public RO
snmp-server community write RW
Пароли, естественно, другие. Еще стоят правила на файрволе, запрещающиен доступ по этому протоколу извне сети, стоят правила на самом маршрутизаторе, разрешающие обмен всеми пакетами внутри сети, в которой находятся маршрутизаторы. В утрированном виде, это небольшая подсеть, существующая только для обмена транспортными данными между маршрутизаторами. Каждый из серверов имеет по интерфейсу в данном сегменте для мониторинга и интерфейс в другой сегмент для отдачи данных фронт-энд серверам статистики. Конкретные разрешенные или запрещенные адреса на маршрутизаторе прописывать нет нужды, только подсеть.