Контроль над пользователями. Как?

Обсуждение технических вопросов по продуктам Novell под Linux, а также *nix систем

Контроль над пользователями. Как?

Сообщение Музалёв Николай » 20 май 2004, 19:19

Уважаемые коллеги! Надеюсь на вашу подсказку в решении нашей проблемы, связанной с получением информации из Сети.

исходное сосотяние:
-имеется сеть на базе серверов NW;
-выход в Сеть основывается на связке LDAP(NW сервер) - SQUID(пограничный ЛИН-сервер) Сами можем (пытаемся) настраивать, но писать под ЛИН серьезно еще не пробовали;
-пользователям разрешено просматривать странички сайтов;
-и запрещено закачивать любые файлы;
-на пограничном сервере организован почтовый сервер;
-каждый пользователь, естественно, имеет почтовый ящик и этому делу элементарно обучен.

необходимо реализовать сл. схему:
-пользователь ползает в Сети и находит необходимый ему файл;

-получает ссылку на этот файл;

-эту ссылку он указывает в письме (??) роботу-качалке типа флашгета/регета (??) ;

-робот получает письмо, извлекает из него ссылку и ставит ссылку в очередь на закачку (типа - очередь заданий);

-и ночью (время регулируется) начинает качать в соответствии с этой очередью;

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

-по исчерпанию списка заданий или по истечению времени, отпущенного роботу, все закаченное разом проверяется на вирус;

-формируется простенький отчет - сколько-кому-откуда-зараза...;

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

Это идеальная схема, ее следует рассматривать как "очень хочется" и вполне возможно, что ваши предложения окажутся еще более инересными, чем я тут нафантазировал. А может уже есть пакет, реализующий такую или подобную схему? А как у вас с этим делом?
Спасибо.
armoracia rusticana (lat.), "блины" и "фиги" всех видов, а также смайлики - крайне не желательны !
Музалёв Николай
 
Сообщения: 3027
Зарегистрирован: 04 июн 2002, 19:58
Откуда: Беларусь. МИНСК.

Сдаётся мне, на заре сети Релком подобные вещи были...

Сообщение Константин Ошмян » 21 май 2004, 13:52

...популярны - доступ куда-то через e-mail интерфейс, обслуживаемый роботом. Посмотрите, например, сюда - что-то похожее Вам нужно? Или, скорее, вот это (ftpmail - a shell program to access to FTP-by-mail services)... В общем, можно поискать по КиАрхиву - может, что-то ещё можно найти. А так - мне кажется, что при некотором навыке программирования можно просто скриптов в Линуксе понаписать и вызывать какой-нибудь wget или даже просто lynx -dump -reload нужный_URL с перенаправлением stdout куда надо для последующей обработки.
Аватара пользователя
Константин Ошмян
 
Сообщения: 974
Зарегистрирован: 13 авг 2002, 21:36
Откуда: Рига

В качестве возможной схемы

Сообщение Андрей Троценко » 21 май 2004, 14:09

1. Пользователь посылает письмо на адрес DownloadThisForMePlease@domain.com
2. Упомянутый адрес ассоциирован с GW API GateWay-ем (предполагается, что вы используете GW)
3. Агент (написанный напр, на Java), периодически сканирует выходной каталог API GateWay-а на предмет новых писем в свой адрес, читает их, извлекает ссылки из отдельных строк письма (1), проверяет каждую из них на разрешение закачивать для данного заказчика (вести отдельный ACL, можно хранить в NDS), и добавляет их в список для downloader-а. Также, агент ведет статистическую БД, в которую пишет заказчика и заказы, а в дальнейшем - рапортует по адресам отправителей.
4. downloader (напр. wget - принимает текстовые файлы списков, и работает с предустановленными куками), в нужный момент (ночью) врубается и качает.
5. На утро, агент (п.3), проверяет закачки, составляет сообщения для получателей, и выкладывает их GW API GateWay-ю. Сами закачки, можно переместить в домашние директории заказчиков.

Т.е., что нужно будет написать самому - это "АГЕНТА" (п.3 и 5). Если интересно, то Java-библиотечку для работы с файлами GW API (самопал, пока только чтение) могу выложить.
Формат заданий (п.3) - как творческая мысля пойдет.

В целом, напр. эта схема не будет работать с download.novell.com из-за того, что кук авторизации "просрочится" до ночи ;-(
Аватара пользователя
Андрей Троценко
 
Сообщения: 529
Зарегистрирован: 31 июл 2002, 13:54
Откуда: Киев, Украина

Re: Контроль над пользователями. Как?

Сообщение Пилютик Михаил » 21 май 2004, 14:28

Музалёв Николай писал(а):Уважаемые коллеги! Надеюсь на вашу подсказку в решении нашей проблемы, связанной с получением информации из Сети.

исходное сосотяние:
...-и запрещено закачивать любые файлы;
...


"запрещено закачивать любые файлы".
Интересно, а как Вы это делаете, административно?
Пилютик Михаил
 
Сообщения: 305
Зарегистрирован: 09 июл 2002, 15:02
Откуда: Минск

Сообщение Музалёв Николай » 21 май 2004, 16:07

а как Вы это делаете, административно?

Ага-ага, еще попросить их на пол не сорить!
Конечно же технически - настройками СКВИДА. Конкретно сказать детали не могу, т.к. пока сам только смотрю из-за плеча лин-админа и учусь, но если интересует , то распрошу его подробно и представлю.
armoracia rusticana (lat.), "блины" и "фиги" всех видов, а также смайлики - крайне не желательны !
Музалёв Николай
 
Сообщения: 3027
Зарегистрирован: 04 июн 2002, 19:58
Откуда: Беларусь. МИНСК.

Сообщение Dmitry Kubov » 21 май 2004, 18:13

Ограничить можно и так (кусок squid.conf):

# TAG: reply_body_max_size (KB)
# This option specifies the maximum size of a reply body. It
# can be used to prevent users from downloading very large files,
# such as MP3's and movies. The reply size is checked twice.
# First when we get the reply headers, we check the
# content-length value. If the content length value exists and
# is larger than this parameter, the request is denied and the
# user receives an error message that says "the request or reply
# is too large." If there is no content-length, and the reply
# size exceeds this limit, the client's connection is just closed
# and they will receive a partial reply.
#
# NOTE: downstream caches probably can not detect a partial reply
# if there is no content-length header, so they will cache
# partial responses and give them out as hits. You should NOT
# use this option if you have downstream caches.
#
# If you set this parameter to zero (the default), there will be
# no limit imposed.
#reply_body_max_size 0
Dmitry Kubov
 
Сообщения: 71
Зарегистрирован: 11 июн 2003, 18:49


Вернуться в *nix

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

cron