информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Сетевые кракеры и правда о деле ЛевинаSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / dnet / faq / персональный прокси
FAQ
главная
общая информация
как принять участие
статистика
клиентская программа
персональный прокси
серверы ключей
завершенные проекты
проект ogr
проект rc5-72
старый командный faq




Подписка:
BuqTraq: Обзор
RSN
РВС
БСК




Персональный прокси

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

Если у вас остались вопросы, связанные с прокси, пишите на help@distributed.net

Также вы можете обращаться с вопросами на лист рассылки proxyper@lists.distributed.net, предварительно подписавшись на него с помощью отправки сообщения "subscribe proxyper" на адрес majordomo@lists.distributed.net.

Также некоторую помощь можно получить на канале #distributed сети EFNet. Это не является официальным механизмом поддержки, но там часто можно встретить опытных администраторов персональных прокси, которые способны помочь в решении возникающих проблем.

Сетевое взаимодействие

Емкость и ее планирование

Протоколирование и генераторы статистики

Разное


Мой прокси часто отключается от Internet и всегда слишком занят попытками соединения с сервером ключей, игнорируя при этом запрашивающих его клиентов.

Параметр connectperiod (интервал между соединениями) так невелик, что ко времени завершения ожидания отклика сервера наступает время очередной попытки соединения. Увеличьте значение connectperiod по крайней мере до нескольких минут, или (лучше) установите режим соединения offline (или lurkonly под win32).


Как происходит работа в оффлайновом режиме?

В оффлайновом режиме прокси никогда не будет пытаться самостоятельно инициировать соединение с сервером, поэтому если у него не будет возможности установить соединение, он в конце концов исчерпает свои накопленные блоки. Вы можете заставить его соединиться с сервером с помощью сигнала SIGALRM под Unix, под Win32 - нажав Ctrl-Break в тот момент, когда его окажется активным (эта возможность отсутствует, если прокси запущен как NT service).


Почему мой прокси не может соединиться с сервером?

В персональном прокси версии 311 была обнаружена ошибка, мешающая ему установить соединение в том случае, если вы расположены за межсетевым экраном, используете промежуточный HTTP-прокси, и указали нецифровое имя хоста в качестве адреса сервера ключей.

НЕкоторые пользователи также имели проблемы с разрешением имен и с другими версиями.

В обоих случаях вы можете попытаться явно указать ip-адрес сервера ключей в proxyper.ini вместо имени хоста. Например:

[KeyServer]
ipaddress=206.109.6.80
port=2064


Я хочу, чтобы мой прокси делал запросы "наверх" к серверам ключей только в определенные периоды времени.

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

Вместо этого мы рекомендуем в качестве метода решения данной задачи сконфигурировать прокси для работы в оффлайновом режиме, и использовать стандартные средства вашей операционной системы для запуска событий, заставляющих прокси сделать сброс накопленных блоков. Под Unix это достигается отправкой сигнала "ALRM" процессу прокси. Под Win32 в настоящее время эта функциональность отсутствует, хотя и планируется в разрабатываемых версиях.

Вместо этого, мы также можете использовать скрипт, который будет модифицировать ini-файл вашего прокси и в соответствующее время менять его режим работы с "online" на "offline" (или наоборот). Далее для рестарта прокси под Unix вы можете послать ему сигнал "HUP", а при запуске в качестве Windows NT Service, можете перезапустить сервис командами "net stop" и "net start".


Как осуществить ручную передачу блоков прокси?

Если у вас есть прокси, неспособный выходить в Internet, еще не все потеряно. Поскольку прокси использует формат буферов, несовместимый с клиентским, мы не можете сбросить буферы прокси просто с помощью другого клиента. Но вы можете проделать следующее:

  1. временно остановить ваш прокси;
  2. ПЕРЕМЕСТИТЬ буферы прокси на другую машину, имеющую выход в Internet;
  3. временно запустить на этой машине персональный прокси, использующий эти буферы, и дань ему соединиться с сервером ключей для передачи/получения блоков;
  4. после завершения передачи остановить прокси на этой машине;
  5. ПЕРЕМЕСТИТЬ буферы обратно на машину с вашим оффлайновым прокси;
  6. запустить его.

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

Кроме того, может оказаться необходимым разрешить "экспертный режим" (expertmode) в ini-файле прокси, имеющего доступ в сеть, для того, чтобы вы могли указать пороговые значения буферов, превышающие 1000 (поскольку у этого прокси не будет информации о количестве запрашиваемых блоков для автоматического задания этих пороговых значений).


Как быть с поддержкой режимов Lurk/Lurkonly в Linux-версиях прокси?

В настоящее время Linux-версия персонального прокси не поддерживает режимов lurk/lurkonly. Однако, чтобы прокси пытался установить соединение с сервером при установленном ppp-соединении, вы можете добавить в свой файл /etc/ppp/ip-up следующие строчки:

/bin/sleep 5
/usr/bin/killall -ALRM proxyper


Мой межсетевой экран не дает прокси делать DNS-запросы.

Вы можете попробовать явно указать ip-адрес одного из наших серверов ключей в файле proxyper.ini.

Заметим, что привязка прокси к ip-адресу может сделать его зависимым от сбоев сервера или сетевых проблем, не дающих связаться с этим адресом. Кроме того, иногда distributed.net приходится менять адреса серверов ключей. Обычно distributed.net поддерживает DNS-записи таким образом, что при обращении к именам хостов выдаются имена только доступных активных серверов.

Другой способ - задать произвольное имя сервера ключей в proxyper.ini, после чего модифицировать свой файл "hosts" таким образом, чтобы он связывал это имя с одним из адресов, которые вы укажете. Под Unix этот файл расположен в /etc/hosts;, в Windows 95/98 - C:\WINDOWS\HOSTS, в Windows NT - C:\WINNT\SYSTEM32\DRIVERS\ETC\HOSTS.

Например, если вы включите следующие строки в файл "hosts", ваша машина не будет пытаться обращаться к DNS-серверу, а случайным образом выберет один из указанных фиктивных адресов (вам следует заменить эти адреса адресами реальных серверов ключей):

10.0.0.1 us.v27.distributed.net
10.0.0.2 us.v27.distributed.net
10.0.0.3 us.v27.distributed.net
10.0.0.4 us.v27.distributed.net


Сколько клиентов может обслуживать одновременно персональный прокси?

Персональный прокси может иметь одновременно до 32 соединений с клиентами. Поскольку клиенты соединяются нечасто, персональный прокси может обслуживать несколько сотен клиентов.


Сколько блоков должен хранить прокси?

В общем случае, вам следует сконфигурировать свой прокси для хранения числа блоков, необходимых для работы ваших клиентов в течение минимум 24 часов или максимум 7 дней. Это, конечно, означает, что реальное число блоков, на которые надо настраивать прокси, зависит от числа и быстроты ваших клиентов.

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

У меня есть отличное сетевое соединение по выделенной линии, поэтому мне на самом деле не так уж и нужен персональный прокси, но я хочу чувствовать себя крутым, поэтому я его использу. На моем прокси хранится 100 блоков, которые используются 6 раз в день моими машинами. До сих пор у меня не было проблем, но это не оправдывает идею использования прокси. Суть в том что вы можете использовать столько блоков, сколько вам нужно. Вам нужно приспособить персональный прокси под свои нужды. Если все ваши машины имеют надежное сетевое соединение, вам скорее всего нет необходимости использовать прокси. Если Internet хорошо работает только на одной машине, тогда сотни блоков достаточно, прокси будет соединяться каждые несколько минут (вы можете это настроить) и забирать при необходимости новые блоки. Если связь ненадежна, то я бы посоветовал хранить примерно по 250 блоков на клиента. Я считаю, что здесь вполне оправдан метод проб и ошибок, чтобы после тестирования нескольких вариантов выбрать наиболее подходящий для вашей сети.

Мой прокси (статистика на http://www.dsmarty.com) обслуживает 110 человек, они используют около 33 тысяч блоков в день, я всегда имею под рукой не менее 25 тысяч и не более 50 тысяч блоков, и эти настройки меня вполне устраивают:

perproxy.ini:
--------
[rc5-64]
minkeysready=25000
maxkeysready=50000


Мой прокси скачивает только 1000 блоков, но мне нужно больше.

Прокси дает вам задать в параметре maxkeysready любое число до 1000. Числа, большие чем 1000, могут интерпретироваться как равные 1000, если он не верит, что вы действительно потребляете так много блоков. Это запланированное поведение, предназначенное для устранения ситуаций, когда пользователи по незнанию запрашивают слишком много блоков, не осознавая реального потенциала закачиваемых блоков.

Заметим, что прокси не модифицирует физически ваш ini-файл, а просто интерпретирует по-своему указанное в нем значение.

Если вы заметили, что ваша производительность, которая выводится прокси, значительно "скачет" (возможно из-за нерегулярных сбросов блоков вашими клиентами), то возможно, вам следует настроить их на более решулярный сброс. Вы также можете попробовать настроить границы, в течение которых определяется средняя скорость, чтобы ваша регулярная активность укладывалась в эти рамки. И последняя возможность - запретить интеллектуальность клиента, включив экспертный режим, описанный ниже.

Если вы читали файл readme, вы могли заметить существование настройки, включающей экспертный режим, который запрещает интеллектуальную обработку тысячеблочного режима. Однако, вам следует быть осторожным при его использовании, поскольку вы таким образом отключаете защиту от закачки неоправданно большого числа блоков.


Мои клиенты соединяются с прокси, но ничего с него не забирают.

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

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

Кроме того, учтите, что в версии клиента 2.8005.453 пороговые значения буферов изменяются в реальном количестве рабочих единиц (вместо пакетов, которые могли содержать переменное число рабочих единиц). Ранее пороговые размеры буферов всегда задавались в пакетах.

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

(Заметим, что пороговые значения буферов персонального прокси всегда измерялись в рабочих единицах, а не пакетах).


Каким образом мой персональный прокси сообщает серверу ключей информацию о почтовых адресах, IP-адресах, платформах, операционных системах и версиях клиентов?

Прокси передает distributed.net информацию о почтовых адресах, IP-адресах, платформах, операционных системах и версиях клиентов точно в том виде, в котором получает ее от клиента. Однако, ip-адрес, передаваемый distributed.net, будет адресом прокси, а не клиента. Посмотрите файл README, поставляемый с прокси, чтобы ознакомиться со списком типов процессоров и операционных систем.


Я не понимаю параметра timestampflag и того, какие комбинации доступны.

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

Доступные значения номеров форматов:
старый стильMM/DD/YY HH:MM:SS1
новый стильYYYY-MM-DD HH:MM:SS2
клиентский стильMmm DD HH:MM:SS3

Множественные флаги, которые можно выбрать:
показовать имя часового пояса64
временные отметки должны указываться в UTC128

Заметим, что флаг "показывать имя часового пояса (64)" имеет смысл только в сочетании с флагом "временные отметки должны указываться в UTC (128)". В этом случае ко всем отметкам времени, отображающимся на экране (но не в логах) будут добавляться буквы "UTC".

Формат по умолчанию - 193, при этом даты/время отображаются в таком же виде, как и у персональных прокси старых версий.

Обратите внимание на то, что параметр timestampflags является комбинацией двух флагов (64 и 128), к которым прибавляется один из первых трех флагов (1, 2 или 3). Эти флаги не являются битовыми масками, и может быть выбран только один из них. Именно поэтому "3" перечислен как отдельный пункт и не является комбинацией "1" и "2". Далее следует список всех возможных комбинаций.

компонентысуммаописание
1 1Локальное время, двузначный год
2 2Локальное время, четырехзначный год
3 3Локальное время, без года
1+128 129Время UTC, двузначный год
2+128 130Время UTC, четырехзначный год
3+128 131Время UTC, без года
1+64+128 193Время UTC, с пометкой, двузначный год (старый стиль отображения)
2+64+128 194Время UTC, с пометкой, четырехзначный год
3+64+128 195Время UTC, с пометкой, без года

Для всех будущих сторонних утилит обработки логов крайне рекомендуется иметь возможность разбора любого из перечисленных форматов. Заметим, однако, что флаг "64" влияет не на лог-файлы, а только на экранный вывод. Кроме того, обычно нет необходимости учитывать часовой пояс (просто рассматривайте все отметки времени в логах как отметки в локальном времени а потом не отображайте в своих результатах название часового пояса). Если же автор сторонней утилиты не намерен поддерживать альтернативные форматы логов, ему следует четко указать, какой именно формат рекомендуется для корректного использования его программы.


Можно ли получить от публичного сервера ключей такую же статистику, как и от прокси?

К сожалению, никак. На персональном прокси статистическая информация извлекается из лог-файлов, в то время как главные прокси просто не работают такие образом, иначе у них быстро бы закончилось дисковое пространство. Объем данных, с которыми они работают, также является причиной того, что они не предоставляют никаких других публичных услуг (типа передачи файлоа), поскольку это съело бы все их пропускную способность.


Мой свежеустановленный прокси не отдает клиентам блоки.

Такая проблема может позникнуть при новой установке прокси версии 311 для обслуживания клиентов, которые ранее напрямую соединялись с серверами dnet. Прокси не будет обслуживать клиентов, если его входные буферы пусты, но он не будет соединяться с сервером для получения блоков до тех пор, пока в его выходном буфере не появятся блоки для отправки. Клиенты сперва пытаются скачать блоки, а при отказе прокси не пытаются отправить результаты. Возникает блокировка.

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


Могут ли мои клиенты использовать буферные файлы персонального прокси?

Нет. Файлы ppbuf*.rc5 несовместимы с буферными файлами клиентов, так что клиенты не могут использовать их напрямую.


Как под Win'9x запустить прокси спрятанным, или хотя бы в трее?

Под Windows NT для работы в скрытом режима вы можете установить его в виде сервиса. Под Win95/98 вы можете использовать одну из многочисленных сторонних утили, позволяющих прятать программы и перемещать их в трей.

Я использую в этих целях программу Hide-It. Она кладет свою иконку в системный трей, на которой вы можете щелкать правой кнопкой мыши и прятать/показывать кнопки панели задач и даже иконки на рабочем столе. Ее можно настроить на автоматическое скрытие приложение при их запуске. Она бесплатна и работает под 95/98/NT: http://www.expocenter.com/hideit/.


Почему не существует персонального прокси для моей операционной системы?

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

  • Прокси не должен распространяться так же широко, как клиент. Полезно иметь клиента для каждой пригодной для использования платформы, поскольку каждая дополнительная машина приносит в сеть новую вычислительную мощность. С прокси картина другая. Даже в большой корпорации или компьютерной лаборатории обычно достаточно единственного удачно расположенного прокси-сервера, чтобы объединить сотни или даже тысячи клиентов. Следовательно очень маловероятно, чтобы среди этого множества машин (предположительно неоднородного) не найдется ни одной машины, использующей одну из платформ, для которых уже существует реализация прокси.
  • Для прокси необходимо обеспечить высокий уровень качества тестирования. Поскольку прокси-серверы в состоянии испортить работу сотен и тысяч использующих их клиентов, необходимо обеспечить качественное тестирование многими независимыми тестерами в целях быстрого обнаружения проблем. В случае менее популярных платформ, очевидно, будет гораздо меньше пользователей, что повышает вероятность того, что ошибка, привязанная к данной платформе, сможет остаться незамеченной в течение долгого времени.
  • Прокси необходимо регулярно обновлять и переносить. Используя все тот же довод о влиянии прокси на множество клиентов, при выпуске новой версии совершенно необходимо быстрое обновление исполняемых файлов для всех платформ. Все популярные платформы, для которых сейчас существуют версии прокси, легко доступны для разработчиков и при необходимости могут быть обслужены одним из нескольких доступных разработчиков. В случае менее популярных платформ мы обычно можем получить одного добровольца, что значительно повышает вероятность его недоступности и уменьшает степерь готовности поддержки версии в течение неопределенного времени.
  • Платформа должна выглядеть жизнеспособной по крайней мере в обозримом будущем. Очень сложно прекратить поддежку платформы после того как она была начата, поскольку пользователи обычно предпочитают использовать программу для своей платформы, даже если было объявлено о том, что данная платформа больше не поддерживается и не должна более использоваться, и даже если использование устаревших версий может привести к порче информации, проходящей через этот сервер.
  • Код персонального прокси также является основой главных прокси и главного сервера ключей. Поскольку один и тот же код используется в качестве основы для главных серверов сети distributed.net, существуют весьма жесткие требования к поддержке высокопроизводительного кода, способного справиться с требуемыми для главных серверов миллионами ежечасных транзакций. Это делает нас гораздо менее гибкими относительно существенных архитектурных изменений, необходимых для соответствия неким эзотерческим требованиям, предъявляемых платформами, которые не предоставляют функциональных интерфейсов, соответствующих интерфейсам поддерживаемых платформ.

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


Автоматический запуск персонального прокси при загрузке системы (Linux).

Далее приведена последовательность запуска/остановки для Linux (систем SysV). Создайте файл '/etc[/rc.d]/init.d/proxyper' со следующим содержимым:

  #!/bin/sh
  if [ -x /path/to/proxyper ]; then
        case "$1" in
                *start)
                        if [ -f /path/to/rc5desproxy.pid ]; then
                                proxyper_pid=$(cat /path/to/rc5desproxy.pid )
                                kill -15 $proxyper_pid
                        fi
                        /path/to/proxyper -detach
                        echo "started distributed.net personal proxy"
                        ;;
                *stop)
                        if [ -f /path/to/rc5desproxy.pid ]; then
                                proxyper_pid=$(cat /path/to/rc5desproxy.pid )
                                kill -15 $proxyper_pid
                                sleep 2
                                echo "stopped distributed.net personal proxy"
                        fi
                        ;;
                *)
                        echo "Syntax: $0 [start|stop]"
                        exit 1
                        ;;
        esac
  fi
  exit 0
Далее создайте символическую ссылку в каждом из каталогов /etc[/rc.d]/rc?.d/ следующим образом:
Для уровней 0, 1 и 6 (halt, single-user и reboot соответственно):
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc0.d/K10proxyper
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc1.d/K10proxyper
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc6.d/K10proxyper
    
Для уровней 2, 3, 4 и 5 (возможны также 7, 8 и 9, но они есть в немногих юниксах):
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc2.d/S90proxyper
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc3.d/S90proxyper
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc4.d/S90proxyper
    ln -s /etc[/rc.d]/init.d/dnetc /etc[/rc.d]/rc5.d/S90proxyper
    
при входе на новый уровень, init(8) запускает скрипты в каталоге /etc[/rc.d]/rc[номер-уровня].d/. Скрипты 'K' - скрипты завершения, которые выполняются при остановке. Скрипты 'S' - стартовые, выполняющиеся при старте. Подробнее о процедуре обработке скриптов можно узнать на man-странице init(8) вашей операционной системы. Таким образом, клиент будет стартовать при входе на уровни 2, 3, 4 или 5, и останавливаться при входе на любой другой уровень исполнения.

Для последних версий Redhat Linux, целесообразней использовать следующий скрипт.

Для установки:

  1. Добавьте скрипт в /etc/rc.d/init.d/proxyper (отредактируйте "path/to" and "runas")
  2. chkconfig --add proxyper

Это автоматически создаст символические ссылки на основе комментариев в начале скрипта. Они будет добавлены в нужные каталоги с нужными именами.

Проверьте свою установку:

chkconfig --list proxyper

Запустите сервис командой

service proxyper start

Сообщения будут выглядеть так же, как и те, что выдаются стартовыми скриптами. The messages will look like the others that are issued by the startup scripts as well.

#!/bin/bash
#
# proxyper      This shell script takes care of starting and stopping
#               rc5des personal proxy.
#
# chkconfig: 2345 86 25
# description: This starts and stops the rc5des personal proxy
# processname: proxyper
# config: /path/to/proxyper
# pidfile: /path/to/proxyper.pid

proxyper="/path/to/proxyper"
pidfile="/path/to/proxyper.pid"
runas="nobody"


# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Source proxyper configureation.
if [ -f /etc/sysconfig/proxyper ] ; then
        . /etc/sysconfig/proxyper
fi

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

[ -x "$proxyper" ] || exit 0

RETVAL=0
prog="proxyper"

start() {
    # Start daemons.

    echo -n $"Starting $prog: "
    if [ -f "$pidfile" ]; then
        proxyper_pid=$(cat "$pidfile" )
        kill -15 $proxyper_pid
    fi
    daemon --user "$runas" "$proxyper" -detach
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
    return $RETVAL
}

stop() {
    # Stop daemons.
    echo -n $"Shutting down $prog: "
    killproc $prog
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
    return $RETVAL
}

# See how we were called.
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        stop
        start
        RETVAL=$?
        ;;
  condrestart)
        if [ -f /var/lock/subsys/$prog ]; then
            stop
            start
            RETVAL=$?
        fi
        ;;
  status)
        status $prog
        RETVAL=$?
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart|condrestart|status}"
        exit 1
esac

exit $RETVAL




Rambler's Top100
Рейтинг@Mail.ru



  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach