Вышел (http://permalink.gmane.org/gmane.network.samba.announce/133) первый кандидат в релизы Samba 3.2.0. Финальный релиз вероятно выйдет в июне или июле. Следующую версию Samba 3.3 рассчитывают выпустить в декабре. Некоторые новшества:- Переход на лицензию GPLv3;
- Поддержка IPv6 и шифрования SMB трафика в сервере, клиентских утилитах и библиотеках;- Поддержка аутентификации клиентов Windows Vista через Kerberos.- Новая клиентская Winbind библиотека (libwbclient.so), распространяемая под лицензией LGPL;- Возможность хранения альтернативных данных в xattrs атрибутах файлов;- Новая NetApi библиотека (libnetapi.so) для выполнения запросов, связанных с входом в домен. Также создан пример простого графического интерфейса на GTK+ для подключения к домену;- Новая клиентская и серверная поддержка удаленного входа в домен и выхода из него.- Поддержка присоединения к Windows 2008 доменам.
- В целях повышения безопасности, изменены значения по умолчанию для около десятка ...URL: http://permalink.gmane.org/gmane.network.samba.announce/133
Новость: http://www.opennet.me/opennews/art.shtml?num=16055
Хочется глянуть на реализацию леса на самбе
эм.. кто-нибудь может объяснить: сможет ли Novel использовать samba 3.2 в своих продуктах?
На условиях GPL3 может :)
но тогда novel придется расторгнуть договор с MS, так?
>но тогда novel придется расторгнуть договор с MS, так?Нет, либо самба не будет подпадать под их договор, либо может быть у МС будут проблемы.
А ну да, любая сфязь с компаниями крутящими сфой роман протиф gplv3 запрещена:))
Реестр рулит. Может быть они смогут очистить обкаканную Майкрософтом хорошую идею хранить конф. параметры в БД.
>Реестр рулит. Может быть они смогут очистить обкаканную Майкрософтом хорошую идею хранить
>конф. параметры в БД.В чём он рулит, не подскажете? Реестр - непанацея!
Когда реестр толстеет с ним неудобно работать (вспомните про "roaming profile").Реестр похож на файловую систему внутри одного файла: там есть и свои текстовые файлы (разделы реестра) и права доступа.
Ну и чего добились? Изобрели велосипед!
Кучка текстовых файлов куда удобнее и надежнее. Главное, чтобы хранение конфигурации программ в тектовых файлах было грамотно спланировано.
Я благодарю Бага за то, что в юнихах до сих пор люди не сделали и не используют поделки аля "майкрософтовский реестр". Одна из самых неудачных идей. На данный момент это один уязвимый файл, который представляет собой гору несметного мусора куда стремится гадить каждая поделка чуть умнее чем "хелло ворлд". Благодаря реестру мой компьютер перестал быть моим - знать что куда записала программа представляется невозможным без каких-либо "снифферов" обращений к реестру, да и то в 95% в реестре находится нечитабельный бред. Теперь судя по статьям майкрософта даже NTP сервер хитро не настроишь на винде без регедита, а если вы его используете, то вас "майкрософт предупреждает". Файловая система внутри файловой системы - это кому пришла в голову идея? И почему это БД лучше для хранения конфигурации????? Ей там теплее что-ли? Или над конфигурацией вы хотите делать аналитические запросы в виде SQL?
* Реестр - единая точка отказа. Видел ситуации когда и "копия" была кривая. А проблемы с открытым реестром при логоффе из за кривых поделок, когда после ребута реестр не остаётся старым?
* Бинарный формат реестра - его самая большая проблема, без микроскопа и 100 грамм не разберёшься.
* юниксовые манагеры пакетов мне скажут куда гадит программа, но знать какие настройки принадлежат какой программе в реестре - как? Как я могу ручками или скриптом "переместить" программу на другой компьютер?
* настройка профиля по умолчанию - ещё та песня
С помощью реестра пользователь и программа пригвождены к этой "БД" как Исус Христос к кресту, только гвоздей - десятки тысяч. И благодаря его отсутствию я полноценный админ юнихов, потому что знаю и легко могу узнать что у меня там к чему.Простите, вырвалось, не мог не отреагировать на рекламную мантру придуманную майкрософтом и повторяемую их адептами потому что "майкрософт это круто".
Во-во!
Кто рулит вашей системой: Вы или издатель дистрибутива?
>Во-во!
>Кто рулит вашей системой: Вы или издатель дистрибутива?LFS? Все по пацански.
>>Во-во!
>>Кто рулит вашей системой: Вы или издатель дистрибутива?
>
>LFS? Все по пацански.Нет. Простой жизненный опыт. LFS даже не пробовал, тока читал.
Если бы текстовые конфиги были стандартизированы, то может быть никому бы и в голову не пришла мысль городИть реестр. Хотя не. В Win3.11 ini-шники уже были стандартизированы, а реестр всё равно создали. В те времена от только для OLE, вроде бы, предназначался.
реестр - крайне ненаглядно и неудобно
отдельные файлы - простое и надежное решение, причем для каждой програмулины свои
если вам нужно быстро что то настроить - есть графические конфигураторы
если вы специалист - к вашим услугам наглядные конфигурационные файлы, зачастую с детальным документированием опций и не перегруженные информацией из других программ
реестр - зло
+1
Согласен по всем пунктам, ибо геморроя с реестром за годы его существования наимелся по самое нехочу.
Особенно "люблю" длинные ключи с вообще никак нечитаемыми названиями в hex, просто опухнуть можно пока найдешь именно ту самую веточку.
>самых неудачных идей. На данный момент это один уязвимый файл, которыйПочему реестр должен быть один? Единый формат а не реестр.
>кому пришла в голову идея? И почему это БД лучше для
>хранения конфигурации????? Ей там теплее что-ли?Это удобнее для программы и админа и появляются новые возможности. Просто пока никто вам не показал это в действии.
>Или над конфигурацией вы хотите
>делать аналитические запросы в виде SQL?БД это не SQL
>* Бинарный формат реестра - его самая большая проблема, без микроскопа и
В компьютере всё бинарно. "Текстовый редактор" показывает текстовое представление бинарного файла используя таблицу соответствия ASCII.
Мля, долбанный Микрософт любую даже самую хорошую идею так обкакает своей идиотской реализацией, что при одном только упоминании принципа у людей галюцинации канализационных потоков перед глазами возникают.
>>самых неудачных идей. На данный момент это один уязвимый файл, который
>
>Почему реестр должен быть один? Единый формат а не реестр.Единый формат для чего? Для отдельных файлов конфигурации? Ну и к чему мы пришли? К бинарникам вместо текстовиков. А выигрыш-то в чем?
По-нормальному, конфигурация считывается ОДИН РАЗ при запуске программы, либо по сигналу админа после изменения настроек, а вовсе не каждую секунду (посмотрите, что выдает regmon). Из реестра получилась БД, с которой идет интенсивный обмен как на чтение, так и на запись.
Более логичным выглядит объяснение, что бинарный формат удобней для коммерческого ПО. Можно, например, предложить дополнительный софт для грамотного бэкапа, с учетом ACL (nbackup не предлагать).
>>кому пришла в голову идея? И почему это БД лучше для
>>хранения конфигурации????? Ей там теплее что-ли?
>
>Это удобнее для программы и админа и появляются новые возможности. Просто пока
>никто вам не показал это в действии.Покажите. Или это Ваше know how?
>В компьютере всё бинарно.До, но работают за компьютерами люди и им удобней www.example.com вместо 192.168.1.1 (совсем уж в бинарный лень переводить :-D)
>Мля, долбанный Микрософт любую даже самую хорошую идею так обкакает своей
>идиотской реализацией, что при одном только упоминании принципа у людей >галюцинации канализационных потоков перед глазами возникают.Тут не поспоришь. Этого у них не отнять, умеют! :-)
Но, честно говоря, не могу придумать оправдания существованию реестра. Для хранения GUID ?
>Но, честно говоря, не могу придумать оправдания существованию реестра. Для хранения GUID
>?Solaris SMF. Суть идеи в том, чтобы дать возможность, во-первых, программам управлять config'ом нормальным машинным способом а не с помощью ковыряния в текстах sed'ом, во-вторых, сделать config читабельным даже в момент внесения в него изменений а не ждать пока админ закроет текстовый редактор. Есть ещё с десяток преимуществ и новых возможностей, но объяснять здесь их не буду так как здешний народ всё равно необходимости в колбасе не видит ибо ковыряются в своих песочницах и верят в то, что это пик прогресса. А может у них такие задачи детские.
>>Но, честно говоря, не могу придумать оправдания существованию реестра. Для хранения GUID
>>?
>
>Solaris SMF.Сорри, в этом нет опыта.
>Суть идеи в том, чтобы дать возможность, во-первых, программам управлять
>config'ом нормальным машинным способом а не с помощью ковыряния в текстах
>sed'омМашина должна работать, а человек - думать. Пусть всякими преобразованиями занимается компьютер, благо, что с конфигами нет нужды интенсивно и ежесекундно работать.
>во-вторых, сделать config читабельным даже в момент внесения в него
>изменений а не ждать пока админ закроет текстовый редактор.Накой чёрт программе без админа вносить изменения в конфиг? Условно говоря, /etc - это "святыня" for root only, для программ - /var и /tmp. Если сам админ "запутался" в инструментах и начал через GUI и тексты одновременно один конфиг править, тут, уж извините, недостаток образования.
>Есть ещё
>с десяток преимуществ и новых возможностей, но объяснять здесь их не
>будуВсе преимущества такие же как первое или ноу хау?!
>так как здешний народ всё равно необходимости в колбасе не
>видит ибо ковыряются в своих песочницах и верят в то, что
>это пик прогресса. А может у них такие задачи детские.Эмоци... Факты в студию! Плиз.... :-)
>>так как здешний народ всё равно необходимости в колбасе не
>>видит ибо ковыряются в своих песочницах и верят в то, что
>>это пик прогресса. А может у них такие задачи детские.
>
>Эмоци... Факты в студию! Плиз.... :-)Необходимость организации ОС как поставщика виртуальных машин осознали умные дядьки в IBM в 70-80-ых годах прошлого века и сделали Mainframe (сейчас System z). Linux, вылазия из песочниц, идёт к этому же. SMF в Solaris тоже не от нечего делать появился, а как необходимость для обеспечения большей управляемости и надёжности. Причём SMF в Solaris не реализовал даже половины тех возможностей, что даёт использование этого принципа. Объяснить словами не хочу так как не поймут. Для демонстрации возможностей нужно писать пример в коде, чтобы можно было вам самим попробовать. Мне пока лень.
>[оверквотинг удален]
>>>это пик прогресса. А может у них такие задачи детские.
>>
>>Эмоци... Факты в студию! Плиз.... :-)
>
>Необходимость организации ОС как поставщика виртуальных машин осознали умные дядьки в IBM
>в 70-80-ых годах прошлого века и сделали Mainframe (сейчас System z).
>Linux, вылазия из песочниц, идёт к этому же. SMF в Solaris
>тоже не от нечего делать появился, а как необходимость для обеспечения
>большей управляемости и надёжности. Причём SMF в Solaris не реализовал даже
>половины тех возможностей, что даёт использование этого принципа.Ну не все тут в курсе, что из себя представляет "SMF в Solaris", я в их числе :-) Расшифруйте хоть в двух словах. Плиз...
>Объяснить словами не
>хочу так как не поймут.Даже не знаю как вежливо ответить на это.
>Для демонстрации возможностей нужно писать пример
>в коде, чтобы можно было вам самим попробовать. Мне пока лень.Алгоритны можно излагать и изображать, не прибегая к кодированию.
> Ну не все тут в курсе, что из себя представляет "SMF в Solaris", я в их числе :-) Расшифруйте хоть в двух словах. Плиз...Solaris 10 SMF - Service Management Facility, новый механизм по описанию конфигураций служб и их управлению, описание служб делаеться в XML формате, _не конфигурационных файлов служб_, а их манифестов для управления их запуском или мониторингом через SMF, тоесть того, как система должна себя вести с этой службой, как запускать, как останавливать, от каких служб зависит эта служба и так далее, после создания такого манифеста его импортируют в SMF репазиторий, он бинарный, работа с ним ведётся через специальную команду, изменения манифестов и прочее проводится через неё, если изменения глобальный, то файл можно выгрузить подретактировать и импортировать снова, в репазитории храниться 3-и снапшота конфигурации каждой службы, тоесть первый снапшот создаётся при импортирование, второй при старте службы, третий при её изменение, тем самым позволяя делать откат изменений, далее SMF следит за состояние служб, если служба по какой-то причине падает, то SMF её перезапускает, если падает какая-то служба необходимая для работы этой, то SMF переведёт эту службу в режим обслуживания, если упавшая служба была критичной для этой, естественно ведутся логи, тоесть это заменя старым скриптам SYS INIT, всё это связано с FMA - Fault Management, тоесть это всё единая система, задача которой противостоять сбоям, производиить самодиагностику и востоновление после сбоев...:)
>[оверквотинг удален]
>файл можно выгрузить подретактировать и импортировать снова, в репазитории храниться 3-и
>снапшота конфигурации каждой службы, тоесть первый снапшот создаётся при импортирование, второй
>при старте службы, третий при её изменение, тем самым позволяя делать
>откат изменений, далее SMF следит за состояние служб, если служба по
>какой-то причине падает, то SMF её перезапускает, если падает какая-то служба
>необходимая для работы этой, то SMF переведёт эту службу в режим
>обслуживания, если упавшая служба была критичной для этой, естественно ведутся логи,
>тоесть это заменя старым скриптам SYS INIT, всё это связано с
>FMA - Fault Management, тоесть это всё единая система, задача которой
>противостоять сбоям, производиить самодиагностику и востоновление после сбоев...:)Спасибо за разъяснения. На Вашем примере видно очень немного сходства с нынешним виндовым реестром. В Солярисе чувствуется хотя бы продуманность и ориентация на определенную сферу применения - отказоустойчивость служб (сервисов). Наверное при мониторинге сотен серверов это может быть полезным.
Не знаю как в Висте, но вплоть до XP на винде не было сделано такого управления службами (хотя что-то частично продикларировано). Но опять же, не нужно воспринимать реестр как панацею и запихивать туда всё подряд. Для восстановления системы это крайне неудобно.
Реестр - это бинарный файл (файлы).
А когда применяются бинарные файлы?
1) Для упрощения работы пионэров-программистов. Им лень или они просто не знают нужных средств в языке.
2) Для подсаживания клиента на "иглу". Очень выгодно для коммерческого ПО.
3) Для ускорения обмена информацией. Фактически речь уже идет о базе данных.Где здесь место для описания настроек программы, которые один раз считали из файла и держим в памяти?
Есть некоторые идеи по хранению настроек программ в MySQL, например. Идея имеет право на жизнь. Наверное, хостерам с огромной клиентской базой это будет удобно. Админам огромного количества серверов, наверное, это тоже покажется удобным. НО!
Полагаю, что при наличии транзакций, нормальных локов и версионности в файловой системе, аналогичный инструментарий может работать и с обычными текстовыми конфигами. И даже в распределенной среде c централизованным управлением. Примеры есть. Возьмите хотя бы Check Point.
Прелесть UNIX в том, что при всей его мощности и кажущейся сложности он остается ПРОЗРАЧНЫМ и понятным, основываясь на таких базовых понятиях как "файл". И то, что в свободных и открытых реализациях до сих пор придерживаются текстовых конфигов - тому подтверждение.
>Solaris 10 SMF - Service Management Facility, новый механизм по описанию конфигураций
>служб и их управлению, описание служб делаеться в XML формате, _не
>конфигурационных файлов служб_, а их манифестов для управления их запуском или
>мониторингом через SMF, тоесть того, как система должна себя вести с
>этой службой, как запускать, как останавливать, от каких служб зависит эта
>служба и так далее, после создания такого манифеста его импортируют в
>SMF репазиторий, он бинарный, работа с ним ведётся через специальную команду,простите заранее, Вы случайно не жертва семинара по Solaris 10 SMF ? :)
serg1224, если чесно не понимаю в чём сходство Solaris 10 SMF с Windows Registry, задачи у них совершенно разные, никто даже не думал придумывать в Sun Solaris 10 какой-то единный реестр для сохранения или управления конфигурационными файлами служб, SMF - это скорее просто новый подход к управлению запуском служб и их мониторингом, так же, как и в GNU/Linux сейчас меняют старый способ запуска через SYS INIT, на UPStart, это примерно то же самое, только метод описания и хранения выбран ввиде XML, и бинарного репазитория, ввиду необходимлости управления снапшотами, или хранения состояний служб...:)
>serg1224, если чесно не понимаю в чём сходство Solaris 10 SMF сне мешай человеку выговорится
>serg1224, если чесно не понимаю в чём сходство Solaris 10 SMF с
>Windows Registry, задачи у них совершенно разные, никто даже не думалДа забудьте вы это слово "Registry". Важен сам подход - хранение cfg в формате, который удобен для разбора и составления программным способом а не вручную. Что касается дружелюбности к человеку. Если формат cfgdb будет единым как ASCII для текстовых конфигов, то для админа нет никакой разницы запускать текстовый редактор или какой-нибудь cfgedit.
Преимущества:
1) программистам не нужно каждый раз изобретать формат своих текстовых конфигов со всякими способами как засунуть список в переменную, как экранировать специсимвол в значении (пробел, знак равно), как программе сказать, что 09 это строка символов а не число и т.д., они просто используют библиотеку для работы с cfgdb;
2) при установке программы или её обновлением скрипт установки или менеджеры пакетов не будут ковыряться в конфигах sed'ом а будут использовать опять-таки библиотеку libcfgdb;
3) программист программы получает возможность в схему встроить подсказки к параметрам, которые сейчас оформляют в виде кооментариев к конфигу-примеру и которые сильно замусоривают его, снижая наглядность а удалять их не всегда хочется - вдруг позже пригодится, эти подсказки можно сделать выдимыми в cfgedit;
4) для параметров, значения которых должны являтся членом какого-то множества (типа yes-no или low-medium-high или [1-2] и т.д.) cfgedit может выполнять проверку на ошибки ввода или даже давать выбор из списка и ничего более;
5) cfgedit может автоматически увеличивать номер версии cfgdb после каждого редактирования, вспомним файлы описания зон BIND'а и как многие забывают обновить номер версии после внесения изменений;
6) сетевые сервисы, которые динамически запускают и останавливают множественные экземпляры должны иметь постоянную возможность читать cfg - cfgdb можно редактировать без останова обслуживания и боязни сделать промежуточный нечитаемый cfg.И т.д. и т.п. .
>Да забудьте вы это слово "Registry". Важен сам подход - хранение cfg
>в формате, который удобен для разбора и составления программным способом а
>не вручную. Что касается дружелюбности к человеку. Если формат cfgdb будет
>единым как ASCII для текстовых конфигов, то для админа нет никакой
>разницы запускать текстовый редактор или какой-нибудь cfgedit.Если админ сможет остаточно просто и быстро изменить настройки программы, загрузившись с дискетки или подсунув HDD на другую машину, то особых проблем нет. Сейчас надежность инструмента гарантируется его простотой.
Кстати, есть и другой выход - компиляция тектового конфига в двоичный формат в т.ч. в БД, например, в Berkeley DB.
>Преимущества:
>1) программистам не нужно каждый раз изобретать формат своих текстовых конфигов со
>всякими способами как засунуть список в переменную, как экранировать специсимвол в
>значении (пробел, знак равно), как программе сказать, что 09 это строка
>символов а не число и т.д., они просто используют библиотеку для
>работы с cfgdb;Даже на винде для работы с ini-шниками есть специальные функции в API. Двоичные данные можно хранить в HEX или в отдельном двоичном файле, например в БД.
В текстовых файлах нужно хранить настройки МИНИМАЛЬНО необходимые для запуска программы. Данные, которыми оперирует программа, изменяет их, нужно хранить в БД.
Может я чего не догоняю? Приведите пример для наглядности.
>2) при установке программы или её обновлением скрипт установки или менеджеры пакетов
>не будут ковыряться в конфигах sed'ом а будут использовать опять-таки библиотеку
>libcfgdb;Тем не менее сейчас APT на Дебиане как-то справляется. Но я только "ЗА" буду обеими руками, когда появится API (хотя бы рекомендованный) для работы с текстовыми конфигами.
>3) программист программы получает возможность в схему встроить подсказки к параметрам, которые
>сейчас оформляют в виде кооментариев к конфигу-примеру и которые сильно замусоривают
>его, снижая наглядность а удалять их не всегда хочется - вдруг
>позже пригодится, эти подсказки можно сделать выдимыми в cfgedit;1) Никто не мешает программисту сделать GUI для работы с конфигом.
2) Никто не мешает сделать админу конфиг только со своими настройками и без комментариев, сохранив копию оригинального файла. Часто свой конфиг при этом получается весьма кратким.
Обратите внимание как сделано в Mozilla Firefox/Thunderbird. Весьма простой GUI для редактирования настроек, только комментариев не хватает.>4) для параметров, значения которых должны являтся членом какого-то множества (типа yes-no
>или low-medium-high или [1-2] и т.д.) cfgedit может выполнять проверку на
>ошибки ввода или даже давать выбор из списка и ничего более;Это уже пользовательские рюшечки. Вполе достаточно сделать
someapp --check-config
до применения новых настроек.>5) cfgedit может автоматически увеличивать номер версии cfgdb после каждого редактирования, вспомним
>файлы описания зон BIND'а и как многие забывают обновить номер версии
>после внесения изменений;Чем это полезно для конфигов? Их нужно реплицировать?
>6) сетевые сервисы, которые динамически запускают и останавливают множественные экземпляры должны иметь
>постоянную возможность читать cfg - cfgdb можно редактировать без останова обслуживания
>и боязни сделать промежуточный нечитаемый cfg.Читать нужно /etc, а писать в /var или /tmp
Приведите, плиз, пример, когда программа должна сама себе настройки менять.
Таки все правильно, осталось написать библиотеку libcfgdb [что-то вроде Win API для работы с ini-файлами]. И попросить всех разработкчиков пользоваться только ею. Что-то мне подсказывает что такое чудо в природе уже существует, но это уже к программистам.
>разницы запускать текстовый редактор или какой-нибудь cfgedit.
>
>Преимущества:Ну вот опять... и зачем изобретать новую библиотеку если есть xml (и куча api к нему под все что движется) и есть xsd (это для любый гуи или vim редакторов) и xslt - это для apt... блин, ну чего ж все такие упертые и ищут "свой путь"?
>"свой путь"?Потому, мой друг, что идеальная программа эта та которая удобна для админа, а не для программиста, которому лень распарсить текстовый конфиг. А поскольку у программ весьма разные задачи, то и разные диалекты конфигураций тоже вполне логичны. Конечно, бардак есть, но как по мне, вполне терпимый, если всё отлично задокументировано и с примерами. Токма и делай копи-пейст да правь свою поправку на ветер.
когда будет хотябы сотня серверов - тогда копипаст не поможет :)
>когда будет хотябы сотня серверов - тогда копипаст не поможеттут люди собрались умные, что-то придумают и для этого случая.
потому что сотня серверов это уже совсем другая проблема
вот именно, "что-то придумают". Это обычно лисапед, который запросто может уронить из-за какого-то глупого бага все 100 серверов :) (бага типа пробела в имени диры или файла)
>serg1224, если чесно не понимаю в чём сходство Solaris 10 SMF с
>Windows RegistryЯ тоже не понимаю. До Вашего объяснения, что такое "Solaris 10 SMF" я о его существовании даже не знал :-D
>* Бинарный формат реестра - его самая большая проблема, без микроскопа и
>100 грамм не разберёшься.а ты чего хочешь - чтобы он текстовый был ?
тогда будет раз в 5 медленнее работать :)
Хотя консольная утилита для экпорта-импорта реестре - это хорошо.>* юниксовые манагеры пакетов мне скажут куда гадит программа, но знать какие
>настройки принадлежат какой программе в реестре - как? Как я могу
>ручками или скриптом "переместить" программу на другой компьютер?Куда пишет программа тебе ни один менеджер пакетов не скажет - хоть Linux,BSD,Windows.
Другое дело, что UNIX-овые программы разумно создают конфиги и настройки в $HOME.
И в документации прямо есть такой раздел - файлы которые использует программа.
Либо это несколько файлов, либо сразу выделяется целый каталог типа ~/.kde.
Хотя разобрать в хитросплетениях ~/.kde тоже непросто, но по крайней мере ясно для чего это.Перенос программы на другой компьютер ?
Берешь и ставишь на другом компьютере - а как иначе ?
А вот с переносом настроек могут быть и будут проблемы - особенно в Windows :)>* настройка профиля по умолчанию - ещё та песня
Это да - особенно в Windows.
В UNIX же с этим просто - многие программы читают сначала сначала юзерский конфиг,
а при его отсутствии читают глобальный конфиг.Или на крайний случай - юзеру в ~ при создании кидаются настроенные конфиги распространенных программ.
А вот если программу добавили позже, когда юзер уже создан ? Проблема.>С помощью реестра пользователь и программа пригвождены к этой "БД" как Исус
>Христос к кресту, только гвоздей - десятки тысяч. И благодаря его
>отсутствию я полноценный админ юнихов, потому что знаю и легко могу
>узнать что у меня там к чему.А вот кстати можно развить идею реестра в Windows.
1) Каждая программа использует файл реестра, хранящийся в ОТДЕЛЬНОМ файле в домашнем каталоге юзера. Сама система Windows использует свой отдельный файл реестра. Отдельные важные части системы могут использовать свои отдельные файлы.
Это касается как HKCU так и HKLM.
2) В документации есть описание важных частей реестра программ и системы.
3) В системе идет стандартный конвертер для перевода бинарного формата реестра в текстовый и обратно.
4) Использование default-ных (глобальных) настроек для программы. Настройки лежат в фиксированном месте ( видимо C:/Documents and Settings/All Users/... ).
5) Добавить еще чего-нибудь по вкусу.>
>Простите, вырвалось, не мог не отреагировать на рекламную мантру придуманную майкрософтом и
>повторяемую их адептами потому что "майкрософт это круто".макрософт - это машина по печатанию денег
причем дурит всех почище MMM :)
>Или на крайний случай - юзеру в ~ при создании кидаются настроенные
>конфиги распространенных программ.
>А вот если программу добавили позже, когда юзер уже создан ? Проблема.Конечно уже давно пора как-то навести порядок в разнообразии описания конфигурации. Блин, у каждого свой синтаксис. Кучу времени уходит на "оригинальные диалекты", а уж о создании универсальных инструментов и речи не идет. Это СВОБОДНО, но неэффективно.
>[оверквотинг удален]
>1) Каждая программа использует файл реестра, хранящийся в ОТДЕЛЬНОМ файле в домашнем
>каталоге юзера. Сама система Windows использует свой отдельный файл реестра. Отдельные
>важные части системы могут использовать свои отдельные файлы.
>Это касается как HKCU так и HKLM.
>2) В документации есть описание важных частей реестра программ и системы.
>3) В системе идет стандартный конвертер для перевода бинарного формата реестра в
>текстовый и обратно.
>4) Использование default-ных (глобальных) настроек для программы. Настройки лежат в фиксированном месте
>( видимо C:/Documents and Settings/All Users/... ).
>5) Добавить еще чего-нибудь по вкусу.И ради чего всё это?! Чтобы сэкономить секунду на запуске программы?
>Конечно уже давно пора как-то навести порядок в разнообразии описания конфигурации. Блин,
>у каждого свой синтаксис.Уже много программ поддерживают хранение конфигурации в LDAP. Чем плохо?
Стандартно, быстро, удобно и программе и админу. Лично я активно пользуюсь.
>>Конечно уже давно пора как-то навести порядок в разнообразии описания конфигурации. Блин,
>>у каждого свой синтаксис.
>
>Уже много программ поддерживают хранение конфигурации в LDAP.Какие, например?
> Чем плохо?
Хорошо!
>Стандартно, быстро, удобно и программе и админу. Лично я активно пользуюсь.
Ссылочку не подкажете?
Осталось где-то хранить настройки для лдапа :)
в /etc/ldap/krb5.keytab ;)
>Возможность хранения альтернативных данных в xattrs атрибутах файлов;видимо, речь о расширенных атрибутах
почитал оригинал - речь там об хранении альтернативных потоков
Почитав о возможностях Samba, и немного поразмыслив сделал один вывод и задал один вопрос.
Вывод -- весьма неплохо поработали разработчки Samba. Респект. Теперь адмнинам гетерогенных сетей будет много [наверное] легче.Вопрос: А на фига столько энергии тратить на то, чтобы обеспечить 100% интеграцию SAMBA с Windows XXXXXXX ?!
Ведь если у меня в обслуживании Windows-сеть, стоит AD на основе Win2003(08) -- то на фига мне Samba с участием в AD-домене? Прокси с централизованной аутентификацией? Почта с централизованной аутентификацией? Но таких наворотов для этих сервисов не нужно, достаточно возможностей Samba 2.x
Может быть просто Windows-сеть, а в качестве контроллера-домена SAMBA? То есть больше 20 рабочих станций под Windows. а сервера по никсами? Тогда получается псевдоэкономия на лицензиях, потому что стоимость админа в таком случае гораздо выше, чем стоимость лицензий на серверную винду.
Или же тогда почему не перейти либо на чистую никсовую сеть, или же сделать сеть с загрузкой рабочих станций по сети и терминальными сеансами? Управление ведь будет тоже централизованным, и при этом от Windows не придется отказываться?Может я чего не понимаю, но мне кажется что, в конце концов, усилия разработчиков SAMBA пропадут впустую, потому как использование такого "мостика" между двумя конкурирующими системами потеряет всякий смысл.
Объясните, а?!
>Вопрос: А на фига столько энергии тратить на то, чтобы обеспечить 100%
>интеграцию SAMBA с Windows XXXXXXX ?!
>Ведь если у меня в обслуживании Windows-сеть, стоит AD на основе Win2003(08)
>-- то на фига мне Samba с участием в AD-домене?За всех не скажу, но у меня такое вИдение.
У меня есть софт, который полезен для нашей конторы и который работает на винде. От винды хочу уйти, чтобы избежать стимулирования перехода на новую версию этой самой винды.Вы не поверите, но когда всё работает, нет никакого желания осваивать СУПЕР-НОВУЮ версию Windows 2xxx.
Ну допустим, Вы не против перехода на новую версию винды. Возможно там даже есть некоторые новые вкусности для Вас. Вы даже не пожалеете денег на новый (ЕЩЕ БОЛЕЕ МОЩНЫЙ) сервер.
Но вот незадача, у Вас есть программа, которая юзает MSSQL2000, а он как-то подглючивает на новой винде. Вы обращаетесь в техподдержку Микрософт и ... что Вам там посоветуют?! Правильно: купить новую версию MSSQL. Зашибись! Вы уже полезли за деньгами в карман и тут (случайно!) узнаёте, что Ваш софт, который работает с MSSQL, каким-то загадочным образом несовместим с новой версией этого самого нового MSSQL.
И здесь вопрос не только в деньгах. Фактически Вам приходится регулярно обновлять ПО без особой на то потребности, собирая при этом новые баги (куда ж без них!).
Коммерсанты всегда заинтересованы в том, чтобы Вы купили у них следующую версию ПО.
>Может быть просто Windows-сеть, а в качестве контроллера-домена SAMBA? То есть
>больше 20 рабочих станций под Windows. а сервера по никсами?Когда Самба4 сможет полностью и самостоятельно эмулировать AD, то Винду гораздо проще будет прогнать из серверной инфраструктуры.
>Тогда получается
>псевдоэкономия на лицензиях, потому что стоимость админа в таком случае гораздо
>выше, чем стоимость лицензий на серверную винду.Cамбу настроил и забыл. В крайних случаях можно запросто админить удаленно даже через GPRS или dial-up.
>Или же тогда почему не перейти либо на чистую никсовую сеть
Огромный виндовый парк может не позволить сделать это одномоментно и безопасно.
>или же сделать сеть с загрузкой рабочих станций по сети и терминальными
>сеансами? Управление ведь будет тоже централизованным, и при этом от Windows
>не придется отказываться?Это уже и сейчас можно сделать. Если Вам не нужна сильно разветвленная AD, то "плоской" архитектуры Самба3 (WinNT4) вполне хватит. Терминальные сервера имеет смысл держать только в случае наличия виндового софта, аналога которому Вы не можете найти на UNIX.
>Может я чего не понимаю, но мне кажется что, в конце концов,
>усилия разработчиков SAMBA пропадут впустую, потому как использование такого "мостика" между
>двумя конкурирующими системами потеряет всякий смысл.А что сечас больше всего держит пользователей на Винде? На мой взгляд так:
1) Привычка
2) Файловый и принтерный сервис, AD
3) Прикладное ПО, которому нет аналогов и которое не работает в WINEНо:
1) Привычки меняются.
2) Samba4 созревает.
3) Разработчики прикладного ПО всё больше обращают внимания на альтернативные платформы. WINE совершенствуется каждый день.Рано или поздно наступит перевес. Я не удивлюсь, если Микрософт будет скоро бесплатно предлагать сервер с базовым функционалом, чтобы хоть как-то притормозить процесс миграции.
>У меня есть софт, который полезен для нашей конторы и который работает
>на винде. От винды хочу уйти, чтобы избежать стимулирования перехода на
>новую версию этой самой винды.
>
>Вы не поверите, но когда всё работает, нет никакого желания осваивать СУПЕР-НОВУЮ
>версию Windows 2xxx.А придется, хотя бы из-за прекращения поддержки и отсутствия апдейтов.
>Но вот незадача, у Вас есть программа, которая юзает MSSQL2000, а он
>как-то подглючивает на новой винде. Вы обращаетесь в техподдержку Микрософт и
>... что Вам там посоветуют?! Правильно: купить новую версию MSSQL. Зашибись!
>Вы уже полезли за деньгами в карман и тут (случайно!) узнаёте,
>что Ваш софт, который работает с MSSQL, каким-то загадочным образом несовместим
>с новой версией этого самого нового MSSQL.Причем тут SAMBA? На ней MSSQL работает?
>
>И здесь вопрос не только в деньгах. Фактически Вам приходится регулярно обновлять
>ПО без особой на то потребности, собирая при этом новые баги
>(куда ж без них!).Вот, вот.
>Когда Самба4 сможет полностью и самостоятельно эмулировать AD, то Винду гораздо проще
>будет прогнать из серверной инфраструктуры.Вот в этом и вопрос. Зачем эмулировать винду, если ее прогонять с серверов? Зачем нужен кривой АД , когда можно настроить то же самое от Novell или использовать NIS?
Проще и дешевле винду в терминальном режиме использовать и не бодаться с AD.>
>Cамбу настроил и забыл. В крайних случаях можно запросто админить удаленно даже
>через GPRS или dial-up.Надежность это плюс. Но что-то я сомневаюсь что про AD на SAMBA4 для виндовой сети можно будет забыть после настройки. Сильно сомневаюсь, ибо вокруг -- винда.
>
>>Или же тогда почему не перейти либо на чистую никсовую сеть
>
>Огромный виндовый парк может не позволить сделать это одномоментно и безопасно.Так можно не одномоментно.
>
>Это уже и сейчас можно сделать. Если Вам не нужна сильно разветвленная
>AD, то "плоской" архитектуры Самба3 (WinNT4) вполне хватит. Терминальные сервераВот я про то и спрашиваю. Если есть сильно разветвленная сеть, требующая централизованного управления, то надежнее и выгоднее использовать никсовые решения, нежели AD от Microsoft.
>имеет смысл держать только в случае наличия виндового софта, аналога которому
>Вы не можете найти на UNIX.См. выше.
>
>А что сечас больше всего держит пользователей на Винде? На мой взгляд
>так:
>1) Привычка
>2) Файловый и принтерный сервис, ADПринтерный, а тем более файловые сервисы гораздо лучше и стабильнее работают под той же Samba 2.x.
>3) Прикладное ПО, которому нет аналогов и которое не работает в WINEЗа исключением банк-клиентов и всяких налоговых программок не вижу других прог, которые было бы нельзя заменить. Тут дело не столько привычки, сколько нежелания переучиваться и отстуствия квалифицированных специалистов. Предвижу что счас мне начнут втирать про CAD'ы, Corel, Photoshop и прочее. Только сначала узнайте, на чем проектируют, например, Боинги или ГАЗы, что используют в Голливуде или попробуйте в своей практике применить хотя бы GIMP вместо Photoshop. Потом можно говорить про виндовый софт. У самого контора на 100% под линухом, и ни у одной типографии ни разу не возникло вопросов по оригинал макетам, и ни разу не было случая искажения оригинал-макета при печати. Хотя печатаем много и часто. Про веб вообще молчу.
>Я не удивлюсь, если Микрософт будет скоро бесплатно предлагать сервер с базовым >функционалом, чтобы хоть как-то притормозить процесс миграции.Это будет совсем кирдык. :-)))))))))
>>Вы не поверите, но когда всё работает, нет никакого желания осваивать СУПЕР-НОВУЮ
>>версию Windows 2xxx.
>
>А придется, хотя бы из-за прекращения поддержки и отсутствия апдейтов.Обновление операционки потянет за собой ворох несовместимостей и багов.
Вот и хочется слезть с этой иглы.>>Но вот незадача, у Вас есть программа, которая юзает MSSQL2000, а он
>>как-то подглючивает на новой винде. Вы обращаетесь в техподдержку Микрософт и
>>... что Вам там посоветуют?! Правильно: купить новую версию MSSQL. Зашибись!
>>Вы уже полезли за деньгами в карман и тут (случайно!) узнаёте,
>>что Ваш софт, который работает с MSSQL, каким-то загадочным образом несовместим
>>с новой версией этого самого нового MSSQL.
>
>Причем тут SAMBA? На ней MSSQL работает?Я привел абстрактный пример, чем ОпенСорс лучше коммерческого ПО (при сохранении функционала, разумеется). Самба - очень хороший аналог коммерческого ПО.
>Надежность это плюс. Но что-то я сомневаюсь что про AD на SAMBA4
>для виндовой сети можно будет забыть после настройки. Сильно сомневаюсь, ибо
>вокруг -- винда.Попробуйте сейчас Самбу3. Весьма качественный продукт. Разработчики уже давно работают над Самба4 и не торопятся с релизом (в хорошем слысле :-) ).
>>Огромный виндовый парк может не позволить сделать это одномоментно и безопасно.
>
>Так можно не одномоментно.Вот здесь Вам Самба и помощник. Поменяли один сервачок. Посмотрели... Подправили чаво надо. Другой поменяли... и так до полного счастья :-)
>>Это уже и сейчас можно сделать. Если Вам не нужна сильно разветвленная
>>AD, то "плоской" архитектуры Самба3 (WinNT4) вполне хватит. Терминальные сервера
>
>Вот я про то и спрашиваю. Если есть сильно разветвленная сеть, требующая
>централизованного управления, то надежнее и выгоднее использовать никсовые решения, нежели AD
>от Microsoft.Надежнее? Возможно. Но вот выгоднее ли? Выгоду каждый измеряет по-своему.
Что для Вас "сильно разветвленная сеть"? Большое количество площадок (сайтов), делегирование администрирования или и то и другое?Если у вас админы только в центре, то возможно Вам подойдет и плоская доменная модель NT4. Самба3 может выступать в роли BDC и PDC.
В AD удобно интегрированы такие ключевые службы как LDAP, DDNS, Kerberos, репликация + поддержка со стороны клиентской винды. В *nix нужно настраивать эти компоненты отдельно, это понятно. Самая большая неприятность заключается в том, что сегодня нет стороннего Кербероса, с которым может работать винда (если я не прав - поправьте меня).
Для себя я решил, что пока останусь на AD и буду ждать Самба4.
>За исключением банк-клиентов и всяких налоговых программок не вижу других прог, которые
>было бы нельзя заменить. Тут дело не столько привычки, сколько нежелания
>переучиваться и отстуствия квалифицированных специалистов.Вот пример:
в коммерческой конторе есть некоторый софт, очень важный для нее, разработчик которой уволился несколько лет назад.>Предвижу что счас мне начнут втирать
>про CAD'ы, Corel, Photoshop и прочее. Только сначала узнайте, на чем
>проектируют, например, Боинги или ГАЗы, что используют в Голливуде или попробуйте
>в своей практике применить хотя бы GIMP вместо Photoshop. Потом можно
>говорить про виндовый софт.Изменение привычки = переквалификация персонала + потеря времени. На это нужны серьезные основания. В крупных конторах обучение персонала происходит планово с закладыванием соответствующих денег в бюджет. Не факт, что это обойдется дешевле покупки виндового софта.
>У самого контора на 100% под линухом,
>и ни у одной типографии ни разу не возникло вопросов по
>оригинал макетам, и ни разу не было случая искажения оригинал-макета при
>печати. Хотя печатаем много и часто. Про веб вообще молчу.Хороший пример! Всем бы так :-)
>В AD удобно интегрированы такие ключевые службы как LDAP, DDNS, Kerberos, репликация + >поддержка со стороны клиентской винды. В *nix нужно настраивать эти компоненты отдельно, >это понятно. Самая большая неприятность заключается в том, что сегодня нет стороннего >Кербероса, с которым может работать винда (если я не прав - поправьте меня).heimdal-kerberos + ldap + samba - в целом неплохое решение (использую у себя), в последних релизах heimdal сильно улучшена работа с виндой. В принципе можно даже без домена работать на локальных аккаунтах (sso/negotiate при этом сохраняется и работает).
>>В AD удобно интегрированы такие ключевые службы как LDAP, DDNS, Kerberos, репликация + >поддержка со стороны клиентской винды. В *nix нужно настраивать эти компоненты отдельно, >это понятно. Самая большая неприятность заключается в том, что сегодня нет стороннего >Кербероса, с которым может работать винда (если я не прав - поправьте меня).
>
>heimdal-kerberos + ldap + samba - в целом неплохое решение (использую
>у себя), в последних релизах heimdal сильно улучшена работа с виндой.
>В принципе можно даже без домена работать на локальных аккаунтах (sso/negotiate
>при этом сохраняется и работает).Вы хотите сказать, что виндовые рабочие станции могут взаимодействовать с heimdal как с виндовым доменом?
Домен это не заменит. В данном случае они взаимодействуют как с Kerberos доменом (винда знает что это такое при правильной настройке) и пользователи аутентифицируются (т.е. пароль проверяется) на KDC, а авторизуются (т.е. все acl доступа к файловой системе например) используя локальную учетную записть. Так же рабочая станция может использовать krb тикет для доступа к керберезированным ресурсам (например samba или apache mod_krb5)http://technet.microsoft.com/ru-ru/library/bb742433(en-us).aspx
>Домен это не заменит.Вот поэтому и ждём Samba4 :-)
>В данном случае они взаимодействуют как с Kerberos
>доменом (винда знает что это такое при правильной настройке) и пользователи
>аутентифицируются (т.е. пароль проверяется) на KDC, а авторизуются (т.е. все acl
>доступа к файловой системе например) используя локальную учетную записть.локальную учетную записть - это ж неудобно.
>
>Вот здесь Вам Самба и помощник. Поменяли один сервачок. Посмотрели... Подправили чаво
>надо. Другой поменяли... и так до полного счастья :-)Так в том то и прикол, что когда все заменил, оказывается самба то не нужна, ибо рабочие станции под никсами удобнее и дешевле. Так может сразу на это и ориентироваться? А не городить огород с "подражанием" AD?
>Так в том то и прикол, что когда все заменил, оказывается самба
>то не нужна, ибо рабочие станции под никсами удобнее и дешевле.
>Так может сразу на это и ориентироваться? А не городить огород
>с "подражанием" AD?Держать Винду только для поддержки AD, без которой совершенно спокойно живется - действительно глупо :-) Подражать этому тоже нет смысла.
У нас агентский бизнес и я, например, не рискую полностью отказываться от Винды, т.к. пока существует весьма высокая вероятность того, что придется устанавливать какой-то чисто Виндовый софт от вышестоящей организации. Всякий раз бороться с WINE-ом не хочу. Тем более, что гарантий никаких.
>Тем более, что гарантий никаких.как говорится, "ололо на башорк". это с виндой гарантий никаких - читай EULA до полного просветления. ты только обязан гарантированно платить деньги за калоподелия, а в остальном - гарантий никаких.
>"гарантий никаких"Я имел в виду, что кем-то разработанный виндовый софт может принципиально не работать под WINE-ом даже после шаманства и "танцев с бубнами". Это чисто технический вопрос и EULA здесь не причем.
Поэтому я считаю благоразумным хотя бы один виндовый терминал-сервер держать в запасе.