From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3C360933.3DEA49A@altlinux.ru> Date: Fri, 04 Jan 2002 22:57:39 +0300 From: Aleksey Novodvorsky Organization: ALTLinux X-Mailer: Mozilla 4.78 [ru] (X11; U; Linux 2.2.20-alt2-up i686) X-Accept-Language: en MIME-Version: 1.0 To: devel@altlinux.ru Content-Type: multipart/mixed; boundary="------------1532A1DD0D69F58A6C3124E0" Subject: [devel] [Fwd: =?koi8-r?Q?=F2=C1=D3=D3=CB=C1=DA=20=CF=C2=20=D5=D3=D4=C1=CE=CF=D7=CB=C5?= ALTLinux] Sender: devel-admin@altlinux.ru Errors-To: devel-admin@altlinux.ru X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: devel@altlinux.ru List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Archived-At: List-Archive: List-Post: This is a multi-part message in MIME format. --------------1532A1DD0D69F58A6C3124E0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Просьба содержательные комментарии отправлять автору нижеследующейго письма, а не только сюда. Rgrds, Алексей --------------1532A1DD0D69F58A6C3124E0 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Content-Disposition: inline >>From aen Fri Jan 4 22:35:52 2002 Return-Path: Delivered-To: aen@localhost.ru.net Received: from abc.neural.ru (unknown [195.96.66.194]) by linux.ru.net (Postfix) with ESMTP id 07A722A10 for ; Fri, 4 Jan 2002 22:35:50 +0300 (MSK) Received: from fire.neural.ru (fire.neural.ru [192.168.1.2]) by abc.neural.ru (8.12.1/8.12.1) with ESMTP id g04JZghl006798 for ; Fri, 4 Jan 2002 22:35:42 +0300 Received: from fire.neural.ru (localhost.localdomain [127.0.0.1]) by fire.neural.ru (8.11.0/8.11.0) with SMTP id g04Ke3L17328 for ; Fri, 4 Jan 2002 23:40:03 +0300 Content-Type: Multipart/Mixed; charset="koi8-r"; boundary="------------Boundary-00=_RELF702ADAKTSV0WJEEZ" From: Andrey Orlov Reply-To: cray@iig.ru To: aen@altlinux.ru Subject: =?koi8-r?b?8sHT08vB2iDPwiDV09TBzs/Xy8U=?= ALTLinux Date: Fri, 4 Jan 2002 23:40:03 +0300 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Return-Receipt-To: cray@iig.ru X-Chameleon-Return-To: cray@iig.ru X-PRIORITY: 2 (High) Priority: urgent Message-Id: <02010423400303.16854@fire.neural.ru> X-Mozilla-Status2: 00800000 --------------Boundary-00=_RELF702ADAKTSV0WJEEZ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Hi! Похоже, предыдущее письмо затерялось. ----------------------------------------------------------------------- $Id: ОтчетОбУстановкеALT.txt,v 1.8 2001/12/21 02:03:06 cray Exp $' ----------------------------------------------------------------------- ========= Зависимости ========= Мы ставили ваш дистрибутив довольно, хм, странным способом - поочереди все пакеты - а потому заметили ряд погрешностей в зависимостях, которые вряд ли заметны невооружеенным глазом, и, скорее всего остались до сих пор: -- MySQL потребовал установки PerlDB в обязательном порядка. Хотя обратная ситуация была бы не лучше. Разумно ли существование такой зависимости: MySQL не всегда используют вместе с Perl, может быть стоит ее подавить? -- Никому в голову не придет ставить линух без пакета filesystem, но у нас такое получилось: зависимости это допустили. Соотв., последующие пакеты, используеющие каталог, например, /var/tmp, отказались ставится без видимых причин: т.к. такой зависимости в них не было. Если нам не изменяет память, это были все пакеты perl*; ======== Добавленные пакеты ======== Ряд пакетов для перла нам пришлось добавить. Честно говоря, меня удивило, что они не вошли в ваш дистрибутив, т.к. пакеты, вообще-то, весьма часто используемые: нам приходилось по их поводу неоднократно вступать в, хм, полемику с различными службами техподдержки провайдеров, и последние хотя и не высказывали любви, но демонстрировали хорошее знакомство с ними. Вот список этих пакетов: perl-HTML-Template-2.4-iig1.src.rpm - это знаменитый HTML::Template; perl-MIME-Base64-2.12-iig1.src.rpm - Кодировщик/декодировщик Base64; perl-MIME-Lite-2.117-iig1.src.rpm - Посылалка писем; perl-MIME-Types-0.06-iig1.src.rpm - Определение MIME-типа по расширению; Мы собрали по вашим примерам для них rpm'ы, и, возможно это неплохо получилось. Хотя мы вряд ли возьмемся их поддерживать, т.к. с перлом работаем все меньше и меньше, но то что собрали можем передать вам: выложить на ftp или закатать на болванку - как вам будет удобнее. Пришлось добавить группу пакетов для питона & Zope, про Zope подробно скажу ниже, про питон вот: MySQL-python-0.9.0-1.i686.rpm - сбсно, коннектор к MySQL. Питон для нас основной язык разработки, да и среда, с нашей точки зрения, должна быть целостной, навено разумно включить пакет в дистрибутив. Наша поддержка возможна, если она актуальна. Кстати, коннектор к PostgreSQL, кажется у вас есть. Либо мы не нашли... Либо вы реально решили ничего такого не добавлять... Но ни одной хоть скольнить серьезной тулзы посвященной IP аудиту в дистриутиве нет, за исключением каких-то малополезных функциональных возможностей в одном из файерволов. Что забавно, такие утилиты существуют. Часть из них мы перетащили под Alt: ipaudit-0.92-0.src.rpm - счетчик & классификатор пролетающих мимо пакетов. Эксплуатация показала, что это весьиа качестенная реализация. ntop-1.3.2-5alt1.src.rpm - это из редхетовского дистрибъюшена. Красиво, реалтаймово, но бесполезно и глючно: подробных логов не ведет, часто падает, в общем, при разговорах с начальством штука бесполезная. Аналогичная мелочь: atsar_linux-1.5-1IIG.src.rpm - сбор статистики использования системы. ========= Вопросы ========= У меня возник ряд вопросов относительно конфигурации пакетов по умолчанию: bind - удивил сконфигуренный по умолчанию сhaosnet. Чесгря, я думал, что это дела давно минувших дней, времен Lisp-машин и институтских сетей. чрутизация - не то, что бы я возражал.... Но были ли какие-то реальные эксплойты на mysql & bind, и стоит ли вообще-то овчинка, хм, выделки? Хотя удивило то, что чрутизация заняла столь мало места. ========= Zope ========= С Zope была чумовая история: несмотря на ваши заверения, у нас есть серъезные опасения, что ситуация не изменилась, т.к. с Zope было два уровня ошибок: скорее всего вы заметили первый, но если вы не эксплуатируете Z, то вряд ли заметили второй. Первый уровень связан с тем, что несколько фрагментов Zope в него в вашей версии не вошли: запускаться он отказался напроч. Скорее всего это было исправлено, но вот краткое переичисление пропущенных файлов: /usr/share/zope/lib/python/Products/PluginIndexes/TextIndex/Splitter /usr/share/zope/lib/python/BTrees /usr/share/zope/lib/python/RestrictedPython Была еще всякая мелочевка, с которой мы справились настолько быстро, что сейчас уже тяжело вспомнить что там было, да и скорее всего это уже устарело. А теперь второй уровень, который, вполне возможно, не исправлен до сих пор: Мы радостно все это дело запустили, перебросили в новый Zope наш тогдашний пакет и начали с ним работать. Через три дня эксплуатации Zope благополучно умер. Вместе с ZODB. Вам будет понятно удивление, если вспомнить, что за предыдущий год не было ни одного сбоя. Мы восстановили данные с бакапа, начали разбираться и вот что выяснилось: Zope из ваших пакетов через два-три дня умирает. Вместе с базой - сам формат базы оказался несовместимым с нормальной версией. Против этого не помогла ни пересборка, ни внимательное изучение вашего пакета: после трех дней попыток исправить ваш пакет мы взяли Z c www.zope.org и пересобрали его оттуда, после чего баги прошли. Ситуацию усугубляло еще и то, что сама планировка инсталляции Zope была в принципе не пригодна для его серьезной эксплуатации. Я понимаю, что она следует рекомендациям DC, но мы с нашим опытом работы с Z привыкли к более серъезным настройкам, равно как к обязательному наличию ряда необязательныъ пакетов ;). История закончилась тем, что мы полностью отказались от использования результатов проекта "Zope RPM", т.к. во-1-ых его результы не жизнеспособны, а во-2-ых структура пакета, с нашей точки зрения, очень слабо учитывает реалии использования Z на полукоммерческом хостинге. Мы собрали свой пакет, разумеется, из DC'шных (www.zope.org) исходников. Основные отличия: 1. Мы ориентируемся на то, что на хосте запущено несколько Z-серверов. Это крайне удобно с точки зрения разработки, эксплуатации и хостинга десятка проектов. Как правило, у нас запущено два Z-сервера, коммерческий и тестовый, иногда доходит до трех. 2. Мы добавили пакеты в питон и в Z: часть наши собственные, в т.ч. кирилический багфикс, часть - чужие. Вот их список: ZProducts-ZMySQLDA-2.7.0-1.src.rpm - коннектор к MySQL, очевидно, стоит добавить еще и коннектор к PostgreSQL: нам он не нужен, но с точки зрения целостности... ZProducts-mysqlUserFolder-0.6.0-1.src.rpm - эта версия основательно пропатчена нами. Специально для MSIE & Russia. Видимо, мы будем связываться с авторами на предмет включения наших патчей. Zope-2.4.2-iig1.src.rpm - это сам Z: о его структуре лучше грить отдельно. CrayFIX, AqGuard, FloodGuard, CrazyGuard, SemanticGuard, RequestDecoder - это все сейчас в стадии разработки. Видимо, будет выложено на сайтах www.neural.ru & www.iig.ru для свободного даунлоада в течении недели-двух. Вот цитата из нашего внутреннего документа поддержки технологии разработки: CrayFIX - русификация ZServer'а Установка пакета вызывает добавление в заголовок ContentType кодировки, без которой ряд грязно реализованных браузеров, таких как MS Internet Explorer, не способны работать с сайтом. Обнаружение в конетексте специальных объектов, таких как libIIGFS и RequestDecoder вызывает добавление ряда полезных функций в менеджерский интерфейс Zope. RequestDecoder - автоматическое декодирование запросов Установка пакета позволяет создать объект, осуществляющий автоматическое распознавание кодировки входящих запросов и перекодирование их в кодировку сервера. Без его установки ряд версий грязно реализованных браузеров, таких как MS Internet Explorer, не способны правильно работать с сайтом. AqGuard & CrazyGuard - защита от сумашедших роботов Особенности объектной модели Zope могут приводить к неограниченной рекурсии индексирующих роботов, превращая их нормальные действия в DoS-атаку против сайта. Установка экземпляра объекта AqGuard позволяет ограничить рекурсию и заблокировать запрос при обнаружении повторного обращения к контейнеру в рамках запроса, а объекта CrazyGuard - обнаружить факт индексации сайта сумашедшим роботом и сгенерировать отказ в доступе или заблокировать обработку запроса при повышенной нагрузке на сайт в этот момент. FloodGuard - защита от флуда Объект FloodGuard дает общее решение проблемы флуда & спамминга веб ресурсов, ограничивая количество обращений к указанным в его конфигурации ресурсам сайта. Ограничение ставится на количество запросов даннного типа за указанный временной интервал с одного и того же IP-адреса. FloodGuard может применятся как к отдельным компонентам сайта так и ко всему сайту в целом. FloodGuard имеет дополнительную возможность: запрет использования защищаемых интерфейсов сайта при обращении к ним из интерфейсов других сайтов, благодаря чему можно заблокировать попытки неопытных спаммеров использовать скрипты для атаки на сайт. Остальные пакеты пока в работе. 3. Zope нужно обслуживать: запускать, останавливать, паковать, бакапить, и т.п.: мы полностью переписали все скрипты окружения, типа /etc/rc.d/init.d/zope, и добавили штук пять своих: неплохие наработки у нас были, хотя их и пришлось обобщить. Теперь это удобно. Наше общее заключение такое: мы готовы предоставить этот набор пакетов. Видимо, мы готовы их поддерживать, хотя о том, что такое поддержка хотоелось бы поговорить подробно. Если это представляет интерес, нам стоит встретится и обсудить такое сотрудничество. ========= Apache ========= Я уже говорил что в апаче бага? В модуле mod_proxy. Честно говоря, у меня так и не дошли руки поднять стенд и воссоздать тестовую ситуацию на вашем русском апаче, но где-то дня через три его работы я увидел до боли знакомые симптомы и Павел пересобрал апач с моим патчем, симптомы после этого прошли, а к этому письму я прилагаю патч, описание баги, обоснование патча и тестовый скрипт. Теперь к апачу претензий, вроде, нет. Хотя баги в этом модуле, безусловно, еще есть - я не шучу, я вижу их проявления, просто это не критично. Далее следуют подробности баги, взятые из нашей переписки с заказчиками, если нужны дополнительные подробности, мы готовы их предоставить, также можем предосавить ваш SRPMS вашего апача, в который патч уже добавлен : == cut : описание баги == Проведенные работы позволили выявить две ошибки в используемых программных средствах: apache 1.3.20 & MSIE 5.00.2920.0000. 1. Ошибка в mod_proxy apache 1.3.20 Условия проявления: - Наличие в кеше mod_proxy ресурса с истекшим временем кеширования, определенным эвристически (т.е. без использования заголовка Expire). - Обращение со стороны клиента к прокси. Причина ошибки: - Прокси выполняет ревалидирование кешированного ресурса с сервером посредством запроса с условием If-Modified-Since . - При получении со стороны сервера ответа со статусом "Not Modified" из-за ошибки в модуле mod_proxy, прокси возвращает кешированный ресурс с заголовками, полученными от сервера в процессе валидации ресурса и не возвращает заголовки, кешированные при более раннем обращении (что нарушает требования RFC2068 & RFC1945). - Среди этих заголовков появляется заголовок Content-Length со значением "0". В соответствии с требованиями RFC2068, UA (MSIE) прекращает загрузку тела содержимого по достижении указанной длины, но не сообщает об этом пользователю, чем в свою очередь также нарушает требования RFC2068. UA HTTP/1.0 (Netscape) докачивает тело содержимого и, как правило корректно, отображает его (за исключением случаев когда опознание типа содержимого сбивается из-за отсутствия заголовка Content-type). - При повторной загрузке через краткий промежуток времени, прокси возвращает только что валидированное содержимое без повторного валидирования, благодаря чему оно возвращается с корректными заголовками. Проявление ошибки: Недокаченные или наполовину докаченные картинки в MSIE, загружающиеся корректно при немедленном повторном обращении к ресурсу. Методы противодействия: - (Рекомендуемый и проверенный) Применить прилагаемый патч к mod_proxy (apache v.1.3.20) ЗАМЕЧАНИЕ: Предлагемый патч может нарушить нормальную работу mod_proxy с HTTP/0.9 серверами (я не то что бы знаю, я просто не проверял). К письму также прилагается патч для mod_proxy (proxy_patch.diff) и тестовая тулза на питоне (proxy_test.py). Рекомендации по использованию тестовой тулзы предоставляются отдельно по запросу: IMHO, исходного кода более чем достаточно, но вот испольованная нами командная строка теста: proxy_test.py -vvv -s 600 fnf.bpn.iig a.lst Где a.lst (список ZImage-морфных ресурсов сервера) - может быть получен посредством manage_findForm. При корректном завершении теста результаты должны быть такими: Тестирование окончено ---------------------- Ошибок HTTP при инициализации кеша 4 Ошибок при первой загрузке (тело,заголовки) (0,0) Ошибок при второй загрузке (тело,заголовки) (0,0) Немодифицированных ресурсов при первой загрузке 0 Немодифицированных ресурсов при второй загрузке 0 Ошибок HTTP при валидировании кеша 0 ---------------------- При некорректном (при обнаружении ошибки) результаты могут быть, например, такими: Тестирование окончено ---------------------- Ошибок HTTP при инициализации кеша 4 Ошибок при первой загрузке (тело,заголовки) (0,15) Ошибок при второй загрузке (тело,заголовки) (0,14) Немодифицированных ресурсов при первой загрузке 0 Немодифицированных ресурсов при второй загрузке 0 Ошибок HTTP при валидировании кеша 0 ---------------------- ЗАМЕЧАНИЕ: 15 & 14 ошибок - это неверно отданные заголовки. Настройки апача 1.3.20: На тестовом сервере использовалась модульная версия (т.е. mod_proxy & mod_rewrite были собраны как модули) со следующими параметрами кеширования: ProxyRequests On CacheRoot "/hosting/pokolenie_ok/cache" CacheSize 1048576 CacheGcInterval 1 CacheMaxExpire 0.1 CacheDefaultExpire 0.05 Сразу замечу, что такие параметры являются суб-оптимальными и не должны использоваться на реальном сервере. == cut == == cut : patch == see attach == cut == == cut : скрипт тестирующий наличие баги == see attach == cut == ========= Perl ========= Perl, тоже падал. Мы используем объектные возможности Perl в конструкторе объекта открываем DBM (dbmopen) и сохраняем ссылку на хеш в атрибуте объекта. В деструкторе мы честно закрываем базу (dbmclose), в этот момент Perl падает. Если базу явно не закрывать, возникает вопрос о том, закроет ли Perl ее коректно, что очень важно для CGI скриптов. Пример скрипта: == cut == #!/usr/bin/perl package Authen; sub new { my $proto = shift; my $class = ref($proto) || $proto; my $self = {}; bless($self,$class); my %LT; dbmopen(%LT, "test_dbmopen", 0666) || die "Can't open test_dbm.db because of $!\n"; $self->{'LT'} = \%LT; return $self; } sub DESTROY { my $self = shift; dbmclose(%{$self->{'LT'}}); return 1; } package main; $test = Authen->new(); == cut == Мы пересобирали Perl с поддержкой разных DB (DB3, DB2, GDB), ошибка проявлялась везде.. ========= Sendmail ========= Здесь тоже были свои проблемы. Скорее настройки, чем баги, но на самом деле хотелось бы узнать: кто-то его поддерживает? Нет-нет, мы не пытаемся предложить нашу кандидатуру, но хотелось бы посоветоваться. С настройкой авторизации у меня были серьезные проблемы, хотя, кажется, я их благополучно решил, а вот starttls в конце-концов пришлось отложить до появления большего количества свободного времени. Опять-таки, ваши сэмплы в этом отношении не были работоспособны, в основном я пользоавался методичкой с sendmail.org. ========= Остальное ========= Остальное - это уже скорее настройки под конкретное применение, и представляют интерес скорее полемический, чем практический, а потому и высказываются только в плане общей полемики: 1. Представляется разумным, имея на борту дистрибутива две базы данных, собирать все пакеты с их поддержкой, если таковая есть. Как пример приведем ProFTPD... Зависимость в этом случае, видимо, лучше попробовать подавить. 2. Представляется разумным, поставлять апач уже настроенный под виртуальный хостинг и с несколько облагороженными ErrorMessage. Есть несколько полуразумных вариантов такой настройки, есть и специальный модуль, и настроить апач самим, конечно, не трудно, но зачем всем каждый раз изобретать велосипед? Не самый лучший вариант есть у нас, но, я думаю, самостоятельной ценности он не представляет, а если такая работа будет проводится - мы бы приняли участие, по крайней мере, в обсуждении. 3. Когда-то давным давно, лет, может быть, даже и 6ть назад, достаный большим количеством файлов ~/.* , я попросил администратора того дуникса дописать в /etc/passwd каталог .home после домашнего, а в .bashrc добавил строчку function cd () { if [ "$1" ]; then command cd "$1"; else command cd ~/..; fi } и перестал все время видеть ~/.*. С тех пор это вошло в привычку. Позже, ситуацию сильно усугубило ~/.kde, ~/public_html, gnome и ряд других аналогичных иерархий: похоже, мы благополучно движемся к тому, что бы понятие "домашнего каталога" разделить на два: каталог с профайлами и рабочий каталог по умолчанию. Свой шаг в этом направлении я уже рассказал: он очень короткий, хотя многие находят его удобным, а не известно ли вам каких-то более серъезных шагов в этом направлении? Правда, hier благополучно заминает вопрос планировки домашних каталогов.... 4. Язык Ruby. Мы обратили внимание на этот пакет в дистрибъюшене, хотелось бы узнать, кем и как он поддерживается. Мы им не пользуемся, но много читали в прессе о проектах на его основе, часть из них представляет для нас интерес, отсюда и вопрос. ----------------------------------------------------------------------- -- Андрей Орлов ведущий инженер IIG 101028, Москва, Хохловский пер., 10, стр. 6 тел.: +7 (095) 9174920 тел/факс: +7 (095) 2582524 www.iig.ru, aorlov@iig.ru --------------Boundary-00=_RELF702ADAKTSV0WJEEZ Content-Type: text/x-c; charset="koi8-r"; name="patch.diff" Content-Transfer-Encoding: base64 Content-Description: =?koi8-r?b?8MHU3iDEzNEgzc/E?= =?koi8-r?b?0NLPy9PJ?= Content-Disposition: attachment; filename="patch.diff" IGRpZmYgLXVyTiBwcm94eS9wcm94eV9odHRwLmMgcHJveHkubmV3L3Byb3h5X2h0dHAuYwotLS0g cHJveHkvcHJveHlfaHR0cC5jCUZyaSBGZWIgIDkgMTU6NDA6MjcgMjAwMQorKysgcHJveHkubmV3 L3Byb3h5X2h0dHAuYwlNb24gSnVuIDE4IDE3OjU4OjQ0IDIwMDEKQEAgLTQ0OSw5ICs0NDksMTAg QEAKIAogLyogbm8gaGVhZGVycyAqLwogCXJlc3BfaGRycyA9IGFwX21ha2VfdGFibGUocCwgMjAp OworLyog6dPQ0sHXzMXOzywg4c7E0sXKIO/SzM/XICovCisgICAgICAgIGMtPmhkcnMgPSByZXNw X2hkcnM7CiAgICAgfQogCi0gICAgYy0+aGRycyA9IHJlc3BfaGRyczsKIAogICAgIGFwX2tpbGxf dGltZW91dChyKTsK --------------Boundary-00=_RELF702ADAKTSV0WJEEZ Content-Type: application/x-python; charset="koi8-r"; name="proxy_test.py" Content-Transfer-Encoding: base64 Content-Description: =?koi8-r?b?9MXT1CDEzNEgzc/E?= =?koi8-r?b?0NLPy9PJ?= Content-Disposition: attachment; filename="proxy_test.py" IyEgL3Vzci9iaW4vcHl0aG9uCiIiIgolcyBbPO/Qw8nJPl0gPMjP09Q+IDzGwcrMINPPINPQydPL z80g0sXT1dLTz9c+IAoK79DDyck6CgktaAn81M/UINTFy9PUCgktdgnzz8/C3cXOydEKCS1pCfTF 09TJ0s/Xwc7JxSDOwSDOxdDPzM7ZyCDawdDSz9PByAoJLW0J9MXT1MnSz9fBzsnFINMg0M/X1M/S ztnNINXTzM/XztnNINrB0NLP08/NCgktdQnp09DPzNjaz9fB1NggSFRUUC8xLjEKCS1zCffSxc3R IM/WycTBzsnRIM3F1sTVINDF0tfPyiDJINfUz9LPyiDT1MHEycXKINTF09TBCgktLWlnbgnpx87P 0snSz9fB1Ngg2sHHz8zP18/LCgktLWFsbAn308Ug2sHHz8zXy8kKIiIiCgppbXBvcnQgc29ja2V0 CmltcG9ydCBwb3NpeAppbXBvcnQgcmUKaW1wb3J0IHN0cmluZwppbXBvcnQgcmFuZAppbXBvcnQg c3lzCmltcG9ydCBnZXRvcHQKaW1wb3J0IG1kNQppbXBvcnQgdGltZQoKdmVyYm9zZV9sZXZlbAkJ PSAwCmlzX2luY29tcGxldGUJCT0gMApzbGVlcAkJCT0gNjAKaWdub3JlZAkJCT0gWydEYXRlJ10K aHR0cF92ZXJzaW9uCQk9ICdIVFRQLzEuMCcKKGVycl9ib2R5MSxlcnJfaGRyMSkJPSAoMCwwKQoo ZXJyX2JvZHkyLGVycl9oZHIyKQk9ICgwLDApCmh0dHBfZXJyb3IxCQk9IDAKaHR0cF9lcnJvcjIJ CT0gMApub3Rtb2RpZnkxCQk9IDAKbm90bW9kaWZ5MgkJPSAwCmlzX2NvbmQJCQk9IDAKSHR0cEVy cm9yCQk9ICfv28nCy8EgSFRUUC3Q0s/Uz8vPzMEnCk5vdE1vZGlmaWVkCQk9ICfyxdPV0tMgzsUg wtnMIM3PxMnGycPJ0s/Xwc4g0yDNz83FztTBINDSxcTZxNXdxcog2sHH0tXay8knCgpkZWYgdmVy Ym9zZShtc2csbGV2ZWw9MSkgOgoJIiIiIPfZ18/EINTSwdPTydLP18/ezs/HzyDTz8/C3cXOydEg IiIiCglpZiBsZXZlbCA8PSB2ZXJib3NlX2xldmVsIDoKCQlzeXMuc3Rkb3V0LndyaXRlKG1zZyAr ICJcbiIpCgkJc3lzLnN0ZG91dC5mbHVzaCgpCQoKZGVmIGVycm9yKG1zZyxlcnI9MCkgOgoJIiIi IPfZ18/EINPPz8Ldxc7J0SDPwiDP28nCy8UgySDX2cjPxCAiIiIKCWlmIGVyciA6CgkJc3lzLnN0 ZG91dC53cml0ZSgi79vJwsvBOiAlc1xuIiAlIG1zZykKCWVsc2UgOgoJCXN5cy5zdGRvdXQud3Jp dGUoIiVzXG4qKiDv0MXSwcPJ0SDawdfF0tvFzsEgKipcbiIgJSBtc2cpCgoJc3lzLnN0ZG91dC5m bHVzaCgpCglzeXMuZXhpdChlcnIpCgpoZHJzX3JlZyA9IHJlLmNvbXBpbGUoJ14oW146XSopOicp CmRlZiBodHRwX2xvYWQoaXRlbSxsYXN0X21vZGlmaWVkPU5vbmUpIDoKCWl0ZW0gPSBzdHJpbmcu c3RyaXAoaXRlbSkKCXZlcmJvc2UoJ1xu9NHOxc0gJXMnICUgaXRlbSwgMikKCWhkcnMgPSB7fQoJ c29jayA9IHNvY2tldC5zb2NrZXQoc29ja2V0LkFGX0lORVQsc29ja2V0LlNPQ0tfU1RSRUFNKQoJ c29jay5jb25uZWN0KCdva2YuYnBuLmlpZycsODApCglmID0gc29jay5tYWtlZmlsZSgncisnLDEp CglmLndyaXRlKCdHRVQgaHR0cDovLyVzLyVzICVzXG4nICUgKGFyZ3NbMF0sc3RyaW5nLnN0cmlw KGl0ZW0pLGh0dHBfdmVyc2lvbikpCiMJcHJpbnQgJ0dFVCBodHRwOi8vJXMvJXMgJXNcbicgJSAo YXJnc1swXSxzdHJpbmcuc3RyaXAoaXRlbSksaHR0cF92ZXJzaW9uKQoJaWYgbGFzdF9tb2RpZmll ZCA6CgkJZi53cml0ZSgnSWYtTW9kaWZpZWQtU2luY2U6ICVzXG4nICUgbGFzdF9tb2RpZmllZCkK IwkJcHJpbnQgJ0lmLU1vZGlmaWVkLVNpbmNlOiAlc1xuJyAlIGxhc3RfbW9kaWZpZWQKCWYud3Jp dGUoJ1xuJykKCQoJc2l6ZSA9IE5vbmUKCXM9Zi5yZWFkbGluZSgpCiMJcHJpbnQgcwoJdHJ5IDoK CQlodHRwX3JlcyA9IGludChzdHJpbmcuc3BsaXQocylbMV0pCglleGNlcHQgOgoJCXJhaXNlIEh0 dHBFcnJvcgoKCWlmIGh0dHBfcmVzICE9IDIwMCA6CgkJaWYgaHR0cF9yZXMgPT0gMzA0IDoKCQkJ dmVyYm9zZSgn79TXxdQ6ICVzIE5vdE1vZGlmaWVkJyAlIGl0ZW0sMSkKCQkJcmFpc2UJTm90TW9k aWZpZWQKCQllbHNlIDoKCQkJdmVyYm9zZSgn79vJwsvBICVzICV1JyAlIChpdGVtLGh0dHBfcmVz KSwxKQoJCQlyYWlzZQlIdHRwRXJyb3IKCQkKCXdoaWxlIGxlbihzKSA6ICMg68HU0Swgz9TXwczJ CgkJaWYgcyA9PSAnXHJcbicgOgoJCQlpZiBzaXplIDoKCQkJCXZlcmJvc2UoJ+7B3snOwcXNINrB x9LV2svVIFVSTCDEzMnOz8ogJXUnICUgc2l6ZSw0KQoJCQkJaWYgaXNfaW5jb21wbGV0ZSA6CgkJ CQkJc2l6ZV9sb2FkID0gaW50KHNpemUgKiBmbG9hdChyYW5kLnJhbmQoKSkvKDIqKjE1LTEpKQoJ CQkJZWxzZSA6CgkJCQkJc2l6ZV9sb2FkID0gc2l6ZQoKCQkJCWJvZHkgPSBmLnJlYWQoc2l6ZV9s b2FkKQoJCQkJdmVyYm9zZSgn+sHH0tXayczJICV1IMnaICV1ICgldSknICUgKHNpemVfbG9hZCxz aXplLGxlbihib2R5KSksNCkKCQkJCWJyZWFrCgkJCWVsc2UgOgoJCQkJdmVyYm9zZSgn5MzJzsEg zsUg1cvB2sHOwSwgy8HewcXNINfTxSDe1M8gxdPU2CcsNCkKCQkJCWJvZHkgPSAiIgoJCQkJd2hp bGUgMSA6CgkJCQkJcyA9IGYucmVhZCg1MTIpCgkJCQkJaWYgbm90IHMgOgoJCQkJCQlicmVhawoJ CQkJCWJvZHkgPSBib2R5ICsgcwoJCQkJYnJlYWsKCQkJCQkKCQllbHNlIDoKCQkJbSA9IGhkcnNf cmVnLm1hdGNoKHMpCgkJCWlmIG0gOgoJCQkJKGIsZSkgPSBtLnJlZ3NbMV0KCQkJCWggPSBzW2I6 ZV0KCQkJCXMgPSBzdHJpbmcuc3RyaXAocykKCQkJCWhkcnNbaF0gPSBzCgkJCQlpZiBoID09ICdD b250ZW50LUxlbmd0aCcgOgoJCQkJCXNpemUgPSBpbnQoc3RyaW5nLnNwbGl0KHMpWzFdKQoJCQkJ dmVyYm9zZSgn7sHKxMXOINrBx8/Mz9fPyyAlcyAoJXMpJyAlIChoLHMpLDUpCgkJcz1mLnJlYWRs aW5lKCkKCglzb2NrLmNsb3NlKCkKCXJldHVybiAoc3RyaW5nLmpvaW4obWFwKGxhbWJkYSB4IDog aGV4KG9yZCh4KSlbMjo0XSxtZDUubWQ1KGJvZHkpLmRpZ2VzdCgpKSwnJyksaGRycykKCmRlZiBo ZWFkZXJfY21wKGhfb2xkLGhfbmV3KSA6CglyZXMgPSAwCglmb3IgaXRlbSBpbiBoX29sZC5rZXlz KCkgOgoJCWlmIGl0ZW0gbm90IGluIGlnbm9yZWQgOgoJCQl0cnkgOgoJCQkJaWYgaF9vbGRbaXRl bV0gIT0gaF9uZXdbaXRlbV0gOgoJCQkJCXJlcyA9IHJlcyArIDEKCQkJCQl2ZXJib3NlKCfuxSDT z9fQwczJINrBx8/Mz9fLySAlc1xuIC0tICVzXG4gLS0gJXMnICUgKGl0ZW0saF9vbGRbaXRlbV0s aF9uZXdbaXRlbV0pLDMpCgkJCWV4Y2VwdCBLZXlFcnJvciA6CgkJCQlyZXMgPSByZXMgKyAxCgkJ CQl2ZXJib3NlKCf3zyDXzs/X2CDP1MTBzs7ZyCDEwc7O2cggzsXUINrBx8/Mz9fLwSAlcycgJSBo X29sZFtpdGVtXSwzKQoKCWZvciBpdGVtIGluIGhfbmV3LmtleXMoKSA6CgkJaWYgaXRlbSBub3Qg aW4gaWdub3JlZCA6CgkJCWlmIG5vdCBoX29sZC5oYXNfa2V5KGl0ZW0pIDoKCQkJCXJlcyA9IHJl cyArIDEKCQkJCXZlcmJvc2UoJ/fPINfOz9fYIM/UxMHOztnIIMTBzs7ZyCDF09TYIMzJ287JyiDa wcfPzM/Xz8sgJXMnICUgaF9uZXdbaXRlbV0sMykKCQkJCglyZXR1cm4gcmVzCgpvcHRzLGFyZ3Mg PSBnZXRvcHQuZ2V0b3B0KHN5cy5hcmd2WzE6XSwiaHV2aW1zOiIsWydpZ249JywnYWxsJ10pCmZv ciBvcHQsdmFsIGluIG9wdHMgOgoJaWYgb3B0ID09ICctaCcgOgoJCXByaW50IF9fZG9jX18gJSBz eXMuYXJndlswXQoJCWVycm9yKCfw0skg19nXz8TFINDPzc/dySDOycvBy8nFIM/QxdLBw8nJIM7F INfZ0M/MztHA1NPRJykKCWVsaWYgb3B0ID09ICctdicgOgoJCXZlcmJvc2VfbGV2ZWwgPSB2ZXJi b3NlX2xldmVsICsgMQoJZWxpZiBvcHQgPT0gJy1pJyA6CgkJdmVyYm9zZSgn99nQz8zO0cXNINTF 09TJ0s/Xwc7JxSDOwSDOxdDPzM7ZyCDawdDSz9PByCcsMSkKCQlpc19pbmNvbXBsZXRlID0gMQoJ ZWxpZiBvcHQgPT0gJy1tJyA6CgkJdmVyYm9zZSgn99nQz8zO0cXNINTF09TJ0s/Xwc7JxSDOwSDV 08zP187ZyCDawdDSz9PByCcsMSkKCQlpc19jb25kCT0gMQoJZWxpZiBvcHQgPT0gJy11JyA6CgkJ dmVyYm9zZSgn4tXExc0gydPQz8zY2s/XwdTYIEhUVFAvMS4xJywxKQoJCWh0dHBfdmVyc2lvbiA9 ICdIVFRQLzEuMScKCWVsaWYgb3B0ID09ICctcycgOgoJCXNsZWVwID0gc3RyaW5nLmF0b2kodmFs KQoJCXZlcmJvc2UoJ/DB1drBICV1INPFy9XOxCcgJSBzbGVlcCwxKQoJZWxpZiBvcHQgPT0gJy0t YWxsJyA6CgkJaWdub3JlZCA9IFtdCgkJdmVyYm9zZSgn8NLP18XS0cXNINfTxSDawcfPzM/Xy8kn LDEpCgllbGlmIG9wdCA9PSAnLS1pZ24nIDoKCQlpZ25vcmVkLmFwcGVuZCh2YWwpCgkJdmVyYm9z ZSgn6cfOz9LJ0tXFzSDawcfPzM/Xz8sgJXMnICUgdmFsLDEpCgoKaWYgbGVuKGFyZ3MpICE9IDIg OgllcnJvcign7sXXxdLOwdEgy8/Nwc7EzsHRINPU0s/LwScpCgp2ZXJib3NlKCfuwd7BzMknLDAp CnZlcmJvc2UoJ+7BwsnXwcXNIMvF28nS1cDdycog0NLPy9PJIMvF28nSz9fBzs7Zzckg0sXT1dLT wc3JJywxKQp1cmxtZDUgPSB7fQoKZm9yIGl0ZW0gaW4gb3BlbihhcmdzWzFdKS5yZWFkbGluZXMo KSA6Cgl0cnkgOgoJCShib2R5LGhkcnMpID0gaHR0cF9sb2FkKGl0ZW0pCgkJaWYgaXNfY29uZCA6 CgkJCXRyeSA6CgkJCQl1cmxtZDVbaXRlbV0gPSAoYm9keSxoZHJzLHN0cmluZy5zdHJpcChoZHJz WydMYXN0LU1vZGlmaWVkJ11bbGVuKCdMYXN0LU1vZGlmaWVkOicpOl0pKQoJCQlleGNlcHQgS2V5 RXJyb3IgOgoJCQkJdmVyYm9zZSgn7sXUINrBx8/Mz9fLwSBMYXN0LU1vZGlmaWVkIC0g1MXT1MnS z9fBzsnFIM7FIMLVxMXUINDPzM7ZzScsMikKCQkJCXVybG1kNVtpdGVtXSA9IChib2R5LGhkcnMp CgkJZWxzZSA6CgkJCXVybG1kNVtpdGVtXSA9IChib2R5LGhkcnMpCglleGNlcHQgKEh0dHBFcnJv cixOb3RNb2RpZmllZCkgOgoJCXZlcmJvc2UoJ+/bycLLwSDQ0skgz8LSwd3FzsnJIMsgJXMnICUg aXRlbSwxKQoJCWh0dHBfZXJyb3IxID0gaHR0cF9lcnJvcjEgKyAxCgoKdmVyYm9zZSgn8MHV2sEg JXUg08XL1c7EJyAlIHNsZWVwLDEpCnRpbWUuc2xlZXAoc2xlZXApCnZlcmJvc2UoJ+TFzMHFzSDQ z9fUz9LO2cog2sHQ0s/TIMnaINDSz8vTyScsMSkKZm9yIGl0ZW0gaW4gdXJsbWQ1LmtleXMoKSA6 CiMJdHJ5IDoKCQlpZiBpc19jb25kIGFuZCBsZW4odXJsbWQ1W2l0ZW1dKSA9PSAzIDoKCQkJbGFz dF9tb2RpZnkgPSB1cmxtZDVbaXRlbV1bMl0KCQllbHNlIDoKCQkJbGFzdF9tb2RpZnkgPSBOb25l CgoJCXRyeSA6CgkJCShib2R5LGhkcnMpID0gaHR0cF9sb2FkKGl0ZW0sbGFzdF9tb2RpZnkpCgkJ CWlmIGJvZHkgIT0gdXJsbWQ1W2l0ZW1dWzBdIDoKCQkJCWVycl9ib2R5MSA9IGVycl9ib2R5MSAr IDEKCQkJCXZlcmJvc2UoJ+/U18XUIM7BINrB0NLP0yDOxSDTz9fQwcwg0NLJINDF0tfPzSDPwtLB 3cXOyckgyyDQ0s/L08kgJXMnICUgaXRlbSwyKQoKCQkJaWYgaGVhZGVyX2NtcCh1cmxtZDVbaXRl bV1bMV0saGRycykgOgoJCQkJZXJyX2hkcjEgPSBlcnJfaGRyMSArIDEKCQkJCXZlcmJvc2UoJ/rB x8/Mz9fLySDP1NfF1MEgzsEg2sHQ0s/TIM7FINPP19DBzMkg0NLJINDF0tfPzSDPwtLB3cXOyckg yyDQ0s/L08kgJXMnICUgaXRlbSwyKQoKCQkJdXJsbWQ1W2l0ZW1dID0gKGJvZHksaGRycykKCgkJ ZXhjZXB0IE5vdE1vZGlmaWVkIDoKCQkJbm90bW9kaWZ5MSA9IG5vdG1vZGlmeTEgKyAxCgkJCXZl cmJvc2UoJ/LF09XS0yAlcyDOxSDC2cwgzc/EycbJw8nSz9fBzicgJSBpdGVtLCAyKQoKCgkJdHJ5 IDoKCQkJKGJvZHksaGRycykgPSBodHRwX2xvYWQoaXRlbSxsYXN0X21vZGlmeSkKCQkJaWYgYm9k eSAhPSB1cmxtZDVbaXRlbV1bMF0gOgoJCQkJZXJyX2JvZHkyID0gZXJyX2JvZHkyICsgMQoJCQkJ dmVyYm9zZSgn79TXxdQgzsEg2sHQ0s/TIM7FINPP19DBzCDQ0skg19TP0s/NIM/C0sHdxc7JySDL INDSz8vTySAlcycgJSBpdGVtLDIpCgoJCQlpZiBoZWFkZXJfY21wKHVybG1kNVtpdGVtXVsxXSxo ZHJzKSA6CgkJCQllcnJfaGRyMiA9IGVycl9oZHIyICsgMQoJCQkJdmVyYm9zZSgn+sHHz8zP18vJ IM/U18XUwSDOwSDawdDSz9MgzsUg08/X0MHMySDQ0skg19TP0s/NIM/C0sHdxc7JySDLINDSz8vT ySAlcycgJSBpdGVtLDIpCgoJCWV4Y2VwdCBOb3RNb2RpZmllZCA6CgkJCW5vdG1vZGlmeTIgPSBu b3Rtb2RpZnkyICsgMQoJCQl2ZXJib3NlKCfyxdPV0tMgJXMgzsUgwtnMIM3PxMnGycPJ0s/Xwc4n ICUgaXRlbSwgMikKCiMJZXhjZXB0IEh0dHBFcnJvciA6CiMJCXZlcmJvc2UoJ+/bycLLwSDQ0skg z8LSwd3FzsnJIMsgJXMnICUgaXRlbSwxKQojCQlodHRwX2Vycm9yMiA9IGh0dHBfZXJyb3IyICsg MQoKdmVyYm9zZSgn9MXT1MnSz9fBzsnFIM/Lz87exc7PJywwKQp2ZXJib3NlKCctLS0tLS0tLS0t LS0tLS0tLS0tLS0tJywwKQp2ZXJib3NlKCfv28nCz8sgSFRUUCDQ0skgyc7Jw8nBzMnawcPJySDL xdvBICV1JyAlIGh0dHBfZXJyb3IxKQp2ZXJib3NlKCfv28nCz8sg0NLJINDF0tfPyiDawcfS1drL xSAo1MXMzyzawcfPzM/Xy8kpICgldSwldSknICUgKGVycl9ib2R5MSxlcnJfaGRyMSksMCkKdmVy Ym9zZSgn79vJws/LINDSySDX1M/Sz8og2sHH0tXay8UgKNTFzM8s2sHHz8zP18vJKSAoJXUsJXUp JyAlIChlcnJfYm9keTIsZXJyX2hkcjIpLDApCnZlcmJvc2UoJ+7Fzc/EycbJw8nSz9fBzs7ZyCDS xdPV0tPP1yDQ0skg0MXS18/KINrBx9LV2svFICV1JyAlIG5vdG1vZGlmeTEsIDApCnZlcmJvc2Uo J+7Fzc/EycbJw8nSz9fBzs7ZyCDSxdPV0tPP1yDQ0skg19TP0s/KINrBx9LV2svFICV1JyAlIG5v dG1vZGlmeTIsIDApCnZlcmJvc2UoJ+/bycLPyyBIVFRQINDSySDXwczJxMnSz9fBzsnJIMvF28Eg JXUnICUgaHR0cF9lcnJvcjIpCnZlcmJvc2UoJy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0nLDApCg== --------------Boundary-00=_RELF702ADAKTSV0WJEEZ-- --------------1532A1DD0D69F58A6C3124E0--