А-ф-ф-игеть!!! прям active directory, ;-) на коленке собранный. круто.

О как!
Будем смотреть.
У меня все руки до этого не доходили.

Опа, первый раз вижу как c LOR-а заслешдотили сервет! Круто.

Смореть бум, когда макс. клиентов больше 30 поднимут... ;-(((

Крут мужик. И главная крутость его в том, что он это все изложил последовательно и внятно. Шапки долой, господа:)

А репозитарий с пакетами? А конфиги выложеные на ftp?

Это уже решение, а не статья...

По моему, сохранение правил iptables сделано некорректно.

сервис iptables не позволяет сохранять и восстанавливать правила по частям.

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

Ну, "умному достаточно" :) Да, конечно, неплохо бы - но и в таком виде это уже очень немало.

Интересно, а нах он начинает ftp транкзацию?

Постоянно вылазит Error 503.

Миня уже ломают?

Я к тому, что репозитарий и конфиги на ftp://ftp.atmsk.ru/pub/prokopiev есть. :)

Это не просто статья, это рабочее решение, запущеное в свободное плавание.

Теперь надо его обстукивать, критиковать и дорабатывать...

Re: Централизованное управление сетевыми ресурсами предприятия.

Ну респекты, даже и сказать нечего. Побольше бы таких статей и решений .

как скажете. поднял.

Картинки то лежат на ftp.

Так быстрее, чем все в zope держать.

Авель, не горячись ;-))) Никто не умаляет заслуг автора. Но ты немного подумай, что будет делать "человек, имеющий минимальные познания в области системного администрирования" с этим "решением", когда будет нужно пронатить с некоторых машин только отдельный порт ? Подсчитать трафик по отдельной сети и/или портам ? Организовать то же самое для двух (и более) ip-сетей ? При преходе с perl5 на perl6 ? ;-))) Опять таки, повотрюсь, никто не умаляет заслуг автора, и за публикацию - ему ОГРОМНЕЙШЕЕ спасибо. Действительно, полезное дело сделал чел. Просто не надо сразу бросаться рвать рубаху на груди, кидать шапку оземь и дудеть в фанфары. ;-)))

Да я не про заслуги.

Просто разговор с гуру в курилке, это одно, статья в журнал, другое, а решение - третье.

Если хорошие статьи у нас еще проскакивают, то решения на 99.9% сделаны в сфере коммерческих предложений.

>Но ты немного подумай, что будет делать "человек, имеющий минимальные >познания в области системного администрирования" с этим "решением", >когда будет нужно пронатить с некоторых машин только отдельный порт ?

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

>Подсчитать трафик по отдельной сети и/или портам ? Организовать то же >самое для двух (и более) ip-сетей ?

Добавить хранимую процедурку, которая выводит нужный отчет? Добавить правило в iptables, чтобы нужный трафик логировался. Это все в рамках данного решения.

>При преходе с perl5 на perl6 ? ;-)))

стандартная задача саппорта.

ЗЫ

Цитатка:

--------------------------------------

3. Итоги

Главное - не конкретные решения, а технология. Предложенные в статье решения применимы без изменений для довольно узкого круга задач. Но описанная технология в любом случае позволяет упростить администрирование небольших локальных сетей. Та же технология с некоторыми изменениями (фактически они сведутся к увеличению настроек, хранимых в LDAP, поддержке новых сервисов и, как следствие, к модификации Network Console) может быть использована для управления более крупными сетями.

---------------------------------------------

такое маленькое ИМХО

Взя прелесть здесь в том что начинающему (в хорошем смысле) админу (ну и не только) показано комплексное рещение, а дальнейщее уточнение man и info.

Экономит очень много времени.

PS. Вспомните как сами начинали :)

Риспект!

LamerOk, а ну ка, напиши хотя бы драфт 0.0.1prealpha схемы поддерживающей: -натить отдельные порты -туда же рулеза по _юзерам_ а не ip. -туда же qos -туда же acl для всего этого (пусть статически транслируемые в скрипт, неважно. главное придумай схему _описания_ всего этого в виде пар key=value или дерева ldap или реляционной бд.)

фишка вот в чем: самый компактный конфиг правил iptables - это скрипт устанавливающий эти правила. ну, с поправкой на воду типа /usr/bin/iptables в каждой строчке.

это опять же к вопросу о скриптах-конфигах.

Помойму после изучения этой статьи можно идти работать админом.

решпект. осталось самбу прикрутить =)

>Помойму после изучения этой статьи можно идти работать админом.

Угу. А после выполнения всех пунктов - можно увольняться - бо никто не заметит =)

> Просто разговор с гуру в курилке, это одно, статья в журнал, другое, а решение - третье.

Вот тут то мы с тобой и расходимся. В вопросе о том, что такое "решение".

> решения на 99.9% сделаны в сфере коммерческих предложений

"Если звезды горят - значит это кому-нибудь нужно", не так ли ? ;-))) Я к тому, что для этого должна быть причина. Решение становится решением только тогда, когда оно _КОМПЛЕКСНО_. Т.е. помимо задачи "работать здесь и сейчас" выполняет массу дополнительных задач, среди которых основная - "работать завтра и послезавтра вопреки всему". "Решения" - это как системность. Это не дискретная величина, а процесс. Может ли данный пример на него претендовать ?

> Но описанная технология в любом случае позволяет упростить администрирование небольших локальных сетей.

Вот это то и спорно. Что именно она позволяет упростить ? Добавление машины в сеть. Какой ценой ? Вот об этом и речь... ;-)))

> Главное - не конкретные решения, а технология.

Ну, "технология" в сфере IT - термин до неприличия размытый. И в данном случае я бы поостерегся его использовать. В данной статье, имхо, действительно главное - это "демонстрация возможностей". Вещь наинужнейшая и полезнейшая, тем паче, что в рунете у нас с этим безумный дефицит. Просто не надо про "решения" кричать... ;-))))

> LamerOk, а ну ка, напиши хотя бы драфт 0.0.1prealpha ... главное придумай схему _описания_ всего этого в виде пар key=value или дерева ldap или реляционной бд.

Чего ты сказать то хотел ? Что сетевые фишки нельзя разложить в той или иной форме хранения данных ? Тогда опредлись для начала в какой именно. В реляционную всю эту ботву запихнуть вообще как два пальца. Проблема будет соотнести с ней окружающую реальность (настройки ната/шлюза/прокси/самбы/etc). Вот за решение этой проблемы как правило и клянчут деньги ;-)))))

>Решение становится решением только тогда, когда оно _КОМПЛЕКСНО_. Т.е. помимо задачи "работать здесь и сейчас" выполняет массу дополнительных задач, среди которых основная - "работать завтра и послезавтра вопреки всему".

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

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

>"Решения" - это как системность. Это не дискретная величина, а >процесс. Может ли данный пример на него претендовать ?

Ну тогда альт сизиф, это решение. Сплощной процесс и 100% системность.

По мне, решение, это то, что можно использовать, а не "процесс".

> Но описанная технология в любом случае позволяет упростить администрирование небольших локальных сетей.

>Вот это то и спорно. Что именно она позволяет упростить ? Добавление машины в сеть. Какой ценой ? Вот об этом и речь... ;-)))

Да. Решение позволяет легко и эффектно вести реестр машин в сети, авторизацию в сети, лимитировать доступ в интернет и вариант доступа.

А цена? Цена минимальна. Поставить согласно описанию конфиги, софт и запустить клиента...

> Главное - не конкретные решения, а технология.

>Ну, "технология" в сфере IT - термин до неприличия размытый. И в данном случае я бы поостерегся его использовать. В данной статье, имхо, действительно главное - это "демонстрация возможностей". Вещь наинужнейшая и полезнейшая, тем паче, что в рунете у нас с этим безумный дефицит. Просто не надо про "решения" кричать... ;-))))

По моему, это как раз решение с демонстрацией его возможностей. В том числе и возможностью расширения.

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

и что дальше? это будет монстр-backend с зависимостями на кучу софта. не путай еще одну либу и решение.

>Проблема будет соотнести с ней окружающую реальность (настройки ната/шлюза/прокси/самбы/etc). Вот за решение этой проблемы как правило и клянчут деньги ;-)))))

Именно такое решение и предложено.

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

По мне, так все то ты попутал ;-))) "реализация задачи" - это рецепт. Решение в обычном общеупотребительном смысле слова. Но никак не решение в смысле IT-сферы. В таком же смысле, в каком употребляеться в выражении "решения на Оракл" и т.п. Про "масштабируемые в сторону" вообще впревые слышу. Найди хоть одно употребление такого выражения нормальным челом применительно к IT. Бывают просто маштабируемые - т.е. могущие работать при _очень_ разных объемах нагрузки и/или ее структуре (sic!). Универсальные же - это как правило просто _ОЧЕНЬ_ масштабируемые ;-)))))

>"решения на Оракл"

Ну так, а тут "решение на файрберде, лдап и яве." В чем противоречие?

>"реализация задачи" - это рецепт.

рецепт, это конфиг с комментарием. В данном случае поставлена и решена задача.

>Про "масштабируемые в сторону" вообще впревые слышу. Бывают просто маштабируемые - т.е. могущие работать при _очень_ разных объемах нагрузки и/или ее структуре (sic!).

Это масштабирование по нагрузке. А когда программу (ОС) можно запустить и в наручных часах и на 256-нодовом кластере? Нагрузка при этом может вообще не рассматриваться...

>Универсальные же - это как правило просто _ОЧЕНЬ_ масштабируемые

Универсальные, это универсальные. Они могут вообще не масштабироваться, а иметь несколько драйверов под оборудование разных производителей. Тот же линукс отдельно масштабируем и отдельно универсален. Ортогональные понятия.

Извиниясь что вмешиваюсь, но почему картинки не грузятся? ((

периодический перегруз ftp

пазор и отстой серваку ftp.atmsk.ru

Пусть лучше mathopd или thttpd запустят.

Хостись у меня :)

> и что дальше?

А почему должно быть что-то дальше ? ;-)))

> это будет монстр-backend с зависимостями на кучу софта.

Ты располагаешь инсайдерской инфой ?? ;-)))))

> не путай еще одну либу и решение.

Так это еще и либа будет ?!?!?! ;-))))))))

P.S. С каких пор ты стал подписываться "anonymous" ? ;-))))

> Ну так, а тут "решение на файрберде, лдап и яве." В чем противоречие?

В том, что у того есть (и будет) поддержка, доки, масшатбируемость и т.п. Это же пока что похвастаться этим не может.

> рецепт, это конфиг с комментарием.

Гнусный поклеп !! ;-))) Конфиг с комментарием - это конфиг с комментарием и ничего больше. ;-))) Рецепт, это ответ на вопрос "Как сделать ххх ?" в духе "То-то настрой так, это вот эдак, потом сюда пропиши вот то, только поставь сначала левый патч вот отсюда, а потом сделай вот так. Если повезет и нигде не облажаешься - получишь свой ххх." ;-)))))

> А когда программу (ОС) можно запустить и в наручных часах и на 256-нодовом кластере?

Кроссплатформенность. ;-))))

> Универсальные, это универсальные.

"Решений для всего и вся не существует в природе." (c) AVL2 ;-)))

> Решение, это готовая реализация задачи. ... По моему, это как раз решение с демонстрацией его возможностей.

Вот в этом то вопросе мы с тобой и расходимся. Решение в IT-сфере это вовсе не решение задачи !!! Это решение ОДНОТИПНОГО КЛАССА ЗАДАЧ.

> Решений для всего и вся не существует в природе. Все решения когда то перестают работать.

Ну про первое то никто и не говорит. А вот во втором - главный вопрос "Когда?". Потому как при принятии _решений_ уже давольно давно один из главных критериев - "как долго оно проработает?".

> Ну тогда альт сизиф, это решение. Сплощной процесс и 100% системность.

В яблочко. Идеальный пример решения. Вот Альт Мастер ХХ.NN - это не решение. Это дистр. А сизиф - решение. Решение для линукс-десктопа, решение для линукс-сервера, и т.д./т.п., но решение.

> По мне, решение, это то, что можно использовать, а не "процесс".

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

Собственно, весь этот терминологический спор я затеял только потому, что лично у меня сразу возникает раздражение, когда помпезными словами "решение", "система управления" и т.п. обозначают что-нибудь простенькое и бесхитростное. Ну, вот как в случае с заголовком этой новости ;-)) Вроде как /etc/login + .bashrc - "система управления пользовательским окружением". Я могу понять, когда какую-нибудь поделку на дельфях для подсчета стеклотары в рекламных целях называют "средством для контроля и управления бизнес-процессом и принятия бизнес-решений на основе финансового анализа". Типа, пора высылать грузовик за собранной стеклотарой или еще подождать пару деньков? Но то же самое на техническом (я прекрасно понимаю всю условность данного эпитета применительно к ЛОРу) сайте ... Сразу режет слух (и глаз).

Блн, /etc/login -> /etc/profile, ес-сно.

> Просто разговор с гуру в курилке, это одно, статья в журнал, другое, а решение - третье.

А комментарии на ЛОРе - четвёртое!

> Шапки долой, господа:)

Шапки давно снесены напрочь, кругом одни слаки теперь ;)

>> Ну тогда альт сизиф, это решение. Сплощной процесс и 100% системность.

>В яблочко. Идеальный пример решения. Вот Альт Мастер ХХ.NN - это не решение. Это дистр. А сизиф - решение. Решение для линукс-десктопа, решение для линукс-сервера, и т.д./т.п., но решение.

Вот теперь все понятно. В моем понимании, такие "решения", как сизиф - гибель ИТ. Они обессмысливают само существование отдельной компьютерной индустрии.

Зы

Насчет анонимуса вообще не понял.

> В моем понимании, такие "решения", как сизиф - гибель ИТ.

Может разовьёшь мысль дальше ? Я в упор не вижу "гибели". Каковы промежуточные леммы ?

> Насчет анонимуса вообще не понял.

Анонимус написал в мой адрес сообщение. Я на него ответил. Ты ответил на это сообщение. Вроде как за анонимуса. ;-)

На мой взгляд, IT, это аналог автомобилестроения. Общепризнано, что автомобиль является локомотивом всего общества. В автопром вбухиваются несоизмеримые с необходимостью в личной "тачке" деньги и эти средства затем растекаются по широчайшему слою подрядчиков. Через автомобиль питается и средняя промышленость и нефтепрм и куча НИИ и т.д. В итоге мы имеем и автомобиль и непрерывный технический прогресс в одном флаконе.

тоже самое и в ИТ. вбухиваются громадные средства и на них вытягиваются целые отрасли, никакого отношения к счетам не имеющие. Это все хорошо, но, чтобы данный механизм работал, на выходе нужно иметь продукт, оплата которого покроет все вложения. Так вот, сизиф отвлекает на себя дикое количество человеческих ресурсов, но что может получиться, если взять за основу сизиф? По моему, ничего... Так что если считать сизиф не ошибкой, а решением, то прогноз спроса на такие решения прощрачен. Его просто не будет. А поскольку основа ИТ, это "завтраки" ("Купите сегодня у нас недоделок типа мсдос, а ЗАВТРА выйдут сервис-паки, патчи, новые версии етк и все буде шоколадно"), то потеря веры заказчика в светлое будущее означает коллапс всей отрасли.

ЗЫ тот ананимус, не я. я просто встрял в ваш разговор.

По юзерам подними ipsec или vpn...

Статья явно рассчитана на тех, кто ни разу в жизни не интересовался локальной сетью. Теперь нужно перенести графическую настройку в начало о опубликовать в журнале "Хакер".

Статья интересная. Часть понравилась - прикручу себе.

Билла Гейтса перечитал?

Кого ты слушаешь? Вон дыры какие - может он их, сволочь, специально плодит?

Странное у вас понимание терминов.

Само по себе слово "Решение" подразумевает, что были исходные данные и из них полученно нечто...

К примеру можно сказать, что сайт pupkin.ru это решение на базе apache или решение на базе php. Просто так не говорят из за очевидности этой фразы. А ваши субъективные реакции на знакомые слова ничего общего с реальностью не имеют.

Еще б виндовых клиентов прикрутить к этой красоте так цены не будет...

нашим предприятиему управляет гкрелм!

Большая работа проделана, снимаю шляпу.

На выходе мы получили инструкцию как собрать кубик рубика, кто-то может подчерпнет рецепты, кто-то не много больше поймет в unix-овом стиле интеграции сервисов в сложную систему.
Но это не готовое решение, это описанияя пути и все. Все здорово, но на коробочное ПО не тянет.
Явно не хватает поддержки MAIL, SAMBA , RADIUS (VPN,dialup), mod_auth_ldap у Апача. Можно найти и эти рецепты и скрутить все скриптиками в нечто единое. Но это опять потребует большой трудоемкости.
Множество людей делали нечто подобное, их многочасовые труды лежат в единичном экземпляре. Самое лучшее,что происходило, появление вот таких статей. Замечательных, но достаточно трудоемких для повторения.
Для уровня среднего и большего предприятия это решение натянуть трудно.

1) Предприятие уже имеет свою информационную структуру, в которой есть БД кадров со штатным расписанием, уровнями полномочий итд итп. Именно в существующей структуре заложено масса информации по ролям в различных системах авторизации.
Кто выдает трафик, следит за использованием PROXY?
Безусловно робот должен поддерживать отключения по лимитам, а начальник и/или уполногмеченное им лицо и/или некая служба имеет право взглянуть на прокачки пользователя и управлять лимитами. Для решения этой задачи придеться использовать структуру организации.

Какой UID должен иметь пользователь в UNIX системах?
Вполне естественно что UID его должен однозначно соотноситься с его цифровым пожизненным идентификатором в БД кадров ( вероятно лучше прибавить 10^6, что бы не было конфликтов с системными uid-ами ). И также логин пользователя один, на всех системах. Пароль - вопрос личной гигиены.

2) Распределнность управления.
Немыслимо обеспечить управления системами авторизации из одной точки.
Любая задача имеет отвественного и не обязательно технаря. Он должен принимать решения кому и что дать, при этом все, кому он что-то разрешает должны быть известны системе, будь то работник или партнер предприятия. ВСЕ ПОЛЬЗОВАТЕЛИ ХРАНЯТЬСЯ ЦЕНТРАЛИЗОВАНО.

3) Из-за сложности процесса управления авторизацией, первоисточником должна стать БД. Она обеспечит целостность данных. Чуть больше проблем чем с LDAP-ом, но это необходимость. LDAP должен выполнять функции раздачи данных по системам, это его хлеб. Он легко интегрируеться практически во все, но поддерживать целостность он не может.

Кроме этого у openLDAP серьезные проблемы с ролями. Все полномочия прописываються в конфигурационный файл. Нельзя построить авторизационную схему на основе внутреннего запроса на наличие какого-либо признака у пользователя, или принадлежность какой-то группе в дереве LDAP. Например у SUN ONE именно так. Разубедите если я не прав.

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

> Если проект будет пытаться дотянуть до уровня среднего предприятия, то ,вероятно, моя писанина будет интересна.

То есть дотянуть до связки AD+Exchange? Не спорю - это бы было очень полезно, особенно если обеспечить совместимость (и соотвественно - совместную работу и миграцию туда и обратно) с AD...

P.S. Порт чтоли соорудить? :)

> нашим предприятиему управляет гкрелм!

а нашим - емакс!