Здравствуйте, Cyberax, Вы писали:
C>Кстати, а есть в Django аналог Spring WebFlow? Т.е. диалог из нескольких страниц, наподобии wizard'а, чтоб ещё нормально кнопку back поддерживал?
Есть Form wizard. Сам не пользовался, так что ничего сказать не могу.
C>Кстати, а что с Ajax'ом? Есть ли прозрачный form submit и обновление страницы (т.е. чтоб оно прозрачно присылало изменённые части DOM-дерева)?
Встроенной поддержки аякса практически нет (есть только необходимый минимум — например для ManyToManyField). Мы юзаем jQuery. В той же статье я отписывал как его юзать.
Здравствуйте, Nuald, Вы писали:
C>>Кстати, а есть в Django аналог Spring WebFlow? Т.е. диалог из нескольких страниц, наподобии wizard'а, чтоб ещё нормально кнопку back поддерживал? N>Есть Form wizard. Сам не пользовался, так что ничего сказать не могу.
Угу. В принципе, пойдёт для сельской местности...
C>>Кстати, а что с Ajax'ом? Есть ли прозрачный form submit и обновление страницы (т.е. чтоб оно прозрачно присылало изменённые части DOM-дерева)? N>Встроенной поддержки аякса практически нет (есть только необходимый минимум — например для ManyToManyField). Мы юзаем jQuery. В той же статье я отписывал как его юзать.
Вот я и спрашиваю. Как-то слишком много ручного труда получается Ну ладно, Ajax пока у нас не приоритетный.
Здравствуйте, Cyberax, Вы писали:
N>>Встроенной поддержки аякса практически нет (есть только необходимый минимум — например для ManyToManyField). Мы юзаем jQuery. В той же статье я отписывал как его юзать. C>Вот я и спрашиваю. Как-то слишком много ручного труда получается Ну ладно, Ajax пока у нас не приоритетный.
В принципе, грамотно написанные AJAX-компоненты не особо трудно прикручиваются. У нас не было проблем ни с MarkItUp!, ни с TinyMCE, ни с компонентами от YUI. Конечно, какой-то бэкенд писать надо, но на питоне с мощными возможностями джанго это не особо трудно.
C>PS: а Pylons, случайно, не использовали?
Слышал, но не использовал. В моих глазах он не достаточно Agile В частности нет автоматически генерируемой админки или даже просто форм, что заставляет писать лишний код. Условно я бы наверное его приравнял к Spring-у.
Здравствуйте, Nuald, Вы писали:
C>>Вот я и спрашиваю. Как-то слишком много ручного труда получается Ну ладно, Ajax пока у нас не приоритетный. N>В принципе, грамотно написанные AJAX-компоненты не особо трудно прикручиваются. У нас не было проблем ни с MarkItUp!, ни с TinyMCE, ни с компонентами от YUI. Конечно, какой-то бэкенд писать надо, но на питоне с мощными возможностями джанго это не особо трудно.
Это не AJAX, это просто контролы.
Скажем, в Wicket'е я можно сделать AJAXовый submit формы буквально двумя строчками кода. То есть, после нажатия "submit" не будет делаться переход между страницами, а просто придут изменившиеся части DOM-дерева.
Как такое сделать в Django мне пока даже не понятно.
C>>PS: а Pylons, случайно, не использовали? N>Слышал, но не использовал. В моих глазах он не достаточно Agile В частности нет автоматически генерируемой админки или даже просто форм, что заставляет писать лишний код. Условно я бы наверное его приравнял к Spring-у.
Spring мне как раз нравится — там можно что угодно к чему угодно подключать. Но да, согласен, Pylons уж очень минималистичный. Правда SQLAlchemy+Genshi весьма привлекательно выглядят. В Django уж очень разметка какая-то невнятная.
Здравствуйте, Cyberax, Вы писали:
C>Скажем, в Wicket'е я можно сделать AJAXовый submit формы буквально двумя строчками кода. То есть, после нажатия "submit" не будет делаться переход между страницами, а просто придут изменившиеся части DOM-дерева. C>Как такое сделать в Django мне пока даже не понятно.
Можно использовать стандартный функционал форм в Django: В коде создать форму (вручную или автоматически сгенерировать из модели, как это делается в админке).
На форму прикрутить html-шаблон (включающую ту часть DOM-дерева которую вы хотите обновлять).
В шаблоне уже приделать нужную логику.
В принципе, через jQuery просто вешается обработчик на click кнопки, который делает сабмит, а бэкэндом уже возвращается новый html (или что-то еще) для обновляемой части шаблона. Можно уложиться и в две строчки, если использовать всю мощь метапрограммирования питона и jquery
Вообще на схожую тему у меня были переговоры с разработчиками Django, и они объяснили мне свою позицию — если редко используемая фича прикручивается к веб-приложению на Django без модификации самого ядра Django, то внедрять эту фичу в ядро они не будут. Надо постараться, чтобы уломать их что-то включить в фреймворк.
N>>Слышал, но не использовал. В моих глазах он не достаточно Agile В частности нет автоматически генерируемой админки или даже просто форм, что заставляет писать лишний код. Условно я бы наверное его приравнял к Spring-у. C>Spring мне как раз нравится — там можно что угодно к чему угодно подключать. Но да, согласен, Pylons уж очень минималистичный. Правда SQLAlchemy+Genshi весьма привлекательно выглядят. В Django уж очень разметка какая-то невнятная.
Genshi как раз к Django и прикручивается — intergrate mako and genshi with django
А вот со всем остальным могут быть проблемы. С другой стороны, как раз к ORM Django почти претензий и нет.
Здравствуйте, Nuald, Вы писали:
N>В принципе, через jQuery просто вешается обработчик на click кнопки, который делает сабмит, а бэкэндом уже возвращается новый html (или что-то еще) для обновляемой части шаблона. Можно уложиться и в две строчки, если использовать всю мощь метапрограммирования питона и jquery
Там далеко не всё так просто, как ты думаешь Я когда-то писал это всё руками (ещё до изобретения слова AJAX) — куча всяких интересных вещей вылезает.
Просто тут без реальной компонентной ориентации сложно что-то нормальное сделать. А компонентным Django не сделать.
N>Вообще на схожую тему у меня были переговоры с разработчиками Django, и они объяснили мне свою позицию — если редко используемая фича прикручивается к веб-приложению на Django без модификации самого ядра Django, то внедрять эту фичу в ядро они не будут. Надо постараться, чтобы уломать их что-то включить в фреймворк.
Если бы оно было, то использовалось бы не так уж и редко. По крайней мере, валидация формы "на лету" с помощью AJAX — это сейчас must have.
C>>Spring мне как раз нравится — там можно что угодно к чему угодно подключать. Но да, согласен, Pylons уж очень минималистичный. Правда SQLAlchemy+Genshi весьма привлекательно выглядят. В Django уж очень разметка какая-то невнятная. N>Genshi как раз к Django и прикручивается — intergrate mako and genshi with django
Только вот кроме этого сниппета я ничего другого не нашёл
N>А вот со всем остальным могут быть проблемы. С другой стороны, как раз к ORM Django почти претензий и нет.
Я привык к возможностям Hibernate, до них Django ORM весьма далеко. А вот SQLAlchemy весьма близка.
Здравствуйте, Cyberax, Вы писали:
N>>В принципе, через jQuery просто вешается обработчик на click кнопки, который делает сабмит, а бэкэндом уже возвращается новый html (или что-то еще) для обновляемой части шаблона. Можно уложиться и в две строчки, если использовать всю мощь метапрограммирования питона и jquery C>Там далеко не всё так просто, как ты думаешь Я когда-то писал это всё руками (ещё до изобретения слова AJAX) — куча всяких интересных вещей вылезает.
Гм, а можно поподробнее? То, что я отписал (валидацию через аякс в джанго), я делал и никаких особо проблем не нашел. jQuery спасает от многих низкоуровневых вещей, типа ручной поддержки кучи браузеров. А вроде других проблем я не вижу.
C>Просто тут без реальной компонентной ориентации сложно что-то нормальное сделать. А компонентным Django не сделать.
Э-э-э, что-то я не особо понял Джанго очень даже из себя компонентный, и как раз работа с компонентами у него идет на ура. Но есть, конечно, кое-где неприятная сильная связанность — типа той аутентификации, или неменяемого ORM.
N>>Вообще на схожую тему у меня были переговоры с разработчиками Django, и они объяснили мне свою позицию — если редко используемая фича прикручивается к веб-приложению на Django без модификации самого ядра Django, то внедрять эту фичу в ядро они не будут. Надо постараться, чтобы уломать их что-то включить в фреймворк. C>Если бы оно было, то использовалось бы не так уж и редко. По крайней мере, валидация формы "на лету" с помощью AJAX — это сейчас must have.
Во-первых, для этого не нужно менять ядро. Есть решения, которые легко внедряются — Django generic AJAX form validation.
Во-вторых, насчет must-have я бы особо не торопился. Возможно, в вашем сегменте это и актуально, а для западного рынка скорость клиентской и серверной валидации практически идентичны. А зачастую AJAX-валидация и не нужна, т.к. используются хитроумные яваскрипт-компоненты (типа поле ввода, которое поддерживает только числа)
N>>А вот со всем остальным могут быть проблемы. С другой стороны, как раз к ORM Django почти претензий и нет. C>Я привык к возможностям Hibernate, до них Django ORM весьма далеко. А вот SQLAlchemy весьма близка.
Django не серебряная пуля, спора нет. Иногда я его искренне ненавижу. Но особо выбора пока и нет — у других фреймворков есть другие недостататки, которые в моих глазах перевешивают достоинства. Хочу посмотреть в сторону Grails, но пока особо не было времени.
Здравствуйте, Nuald, Вы писали:
C>>Там далеко не всё так просто, как ты думаешь Я когда-то писал это всё руками (ещё до изобретения слова AJAX) — куча всяких интересных вещей вылезает. N>Гм, а можно поподробнее? То, что я отписал (валидацию через аякс в джанго), я делал и никаких особо проблем не нашел. jQuery спасает от многих низкоуровневых вещей, типа ручной поддержки кучи браузеров. А вроде других проблем я не вижу.
Для примера смотри сюда: http://www.wicketstuff.org/wicket13/ajax/ (к примеру, вот сюда: http://www.wicketstuff.org/wicket13/ajax/todo-list ). Причём AJAX там обычно добавляется без единой строчки JavaScript'а, просто к компонентам подключается AjaxBehaviour и усё.
C>>Просто тут без реальной компонентной ориентации сложно что-то нормальное сделать. А компонентным Django не сделать. N>Э-э-э, что-то я не особо понял Джанго очень даже из себя компонентный, и как раз работа с компонентами у него идет на ура. Но есть, конечно, кое-где неприятная сильная связанность — типа той аутентификации, или неменяемого ORM.
Я про другую компонентость, когда страница представляет из себя набор компонентов, для которых фреймворк обеспечивает события, lifecycle и т.п.
Кое-что можно эмулировать, но целиком аналог Wicket или ASP.NET сделать не получится.
C>>Если бы оно было, то использовалось бы не так уж и редко. По крайней мере, валидация формы "на лету" с помощью AJAX — это сейчас must have. N>Во-первых, для этого не нужно менять ядро. Есть решения, которые легко внедряются — Django generic AJAX form validation.
Это всё полурешения...
N>Во-вторых, насчет must-have я бы особо не торопился. Возможно, в вашем сегменте это и актуально, а для западного рынка скорость клиентской и серверной валидации практически идентичны. А зачастую AJAX-валидация и не нужна, т.к. используются хитроумные яваскрипт-компоненты (типа поле ввода, которое поддерживает только числа)
Фичи типа красивых переходов между страницами, всяких там AJAX-овых login box'ов — очень популярны. И работают реально намного быстрее полной перерисовки, если правильно делать.
C>>Я привык к возможностям Hibernate, до них Django ORM весьма далеко. А вот SQLAlchemy весьма близка. N>Django не серебряная пуля, спора нет. Иногда я его искренне ненавижу. Но особо выбора пока и нет — у других фреймворков есть другие недостататки, которые в моих глазах перевешивают достоинства. Хочу посмотреть в сторону Grails, но пока особо не было времени.
Я смотрел Grails. Как-то не вставило совсем — активные записи реализованы поверх Hibernate и смотрятся совершенно искусственно и т.п.
Я хотел бы немного разъяснить свою позицию, и направить общение в более конструктивное русло, а то получается уже какой-то флейм: Django — не серебряная пуля, в нем есть свои недостатки и достоинства. Защищать, а тем более восхвалять его не вижу смысла.
Особо упирать на аякс я также не вижу смысла. Если делать сайт для конкретного заказчика под конкретные задачи, скажем, в корпоративном секторе, то да — там можно поставить свои условия, вплоть до того, что все пользователи сайта должны пользоваться исключительно FF 3 с включенным яваскриптом. Однако там, где я работаю, мы ориентируемся на максимальный охват пользователей, включая тех, кто выключает яваскрипт. Аякс конечно мы используем, но лишь как приятное дополнение, и критичной функциональности на него не вешаем.
Я могу ответить на вопросы, как сделать то или иное в Django, или что это сделать нельзя, но сравнение с другими фреймворками — это уже совершенно другая тема. На нее тоже можно поговорить, но лучше в другой ветке.
И несколько слов про мое видение работы с Django.
У Django есть одно несомненное преимущество — сайты на нем пишутся очень быстро. Например, простейшую вики с тегами, поиском, автолинками, минимальной поддержкой форматирования, плюс полностью покрытую юнит-тестами может написать разработчик средней квалификации за один рабочий день. Я не говорю про высококвалифицированных разработчиков — им не важно на чем писать, они напишут на чем угодно очень быстро. Порог вхождения в Python и Django достаточно низкий, и научиться на них работать не займет много времени. Плюс к тому же Django провоцирует на написание более или менее качественного кода (в этом плане использование Genshi только все испортит, т.к. шаблоны на ней позволяют слишком много, вплоть до встраивания методов в шаблоны).
Но, конечно, у Django есть свои недостатки, которые более или менее раскрыты в этой ветке. И в этом плане, разработка на Django очень подходит для прототипирования — быстренько пишется сайт, согласуется с клиентом, кое-что правится и все — альфа версия готова. Теперь уже разработчик решает — использовать ли Django дальше, или переходить на другую, более качественную систему — ту же связку Spring + Hibernate + Velocity + Wicket. Конечно, есть задачи, для которых Django вообще никак не подходит, даже для прототипирования — те же самые Ajax-based приложения. Здесь уже надо смотреть на другие фреймворки, тот же GWT или что-то другое.
Спасибо за ответы!
N>Но, конечно, у Django есть свои недостатки, которые более или менее раскрыты в этой ветке. И в этом плане, разработка на Django очень подходит для прототипирования — быстренько пишется сайт, согласуется с клиентом, кое-что правится и все — альфа версия готова. Теперь уже разработчик решает — использовать ли Django дальше, или переходить на другую, более качественную систему — ту же связку Spring + Hibernate + Velocity + Wicket. Конечно, есть задачи, для которых Django вообще никак не подходит, даже для прототипирования — те же самые Ajax-based приложения. Здесь уже надо смотреть на другие фреймворки, тот же GWT или что-то другое.
Просто когда будет написаный сайт — переписывать его уже хотеться не будет Вот и хочется заранее узнать где подстелить соломку.
Здравствуйте, Cyberax, Вы писали:
C>Просто когда будет написаный сайт — переписывать его уже хотеться не будет Вот и хочется заранее узнать где подстелить соломку.
Здравствуйте, Cyberax, Вы писали:
C>Просто когда будет написаный сайт — переписывать его уже хотеться не будет Вот и хочется заранее узнать где подстелить соломку.
Ну на своей практике я еще не разу не встречался, чтобы пришлось переписывать сайт на Django с нуля (единственный случай, когда пришлось реально переписать очень много кода, и то в основном связанный с админкой — при переходе на версию 1.0). Принципы DRY, которым следует Django, и очень мощная поддержка юнит-тестирования очень серьезно облегчают рефакторинг, и заставляют сразу писать качественный код.
Однако, если спустится с небес на землю, то отпишу какие примерно проблемы могут возникнуть в процессе работы над сайтом, которые могут реально заставить переписать его с нуля:
Производительность. На самом деле Django очень high-scaled фреймворк — то, что на нем крутится New Your Times и блог Медведева с реально ощутимым количеством хитов, о чем-нибудь да говорит. Но если все-таки писать что-то типа Twitter-а или Google-а, то надо тщательно проработь архитектуру. Python может стать очень узким местом, и придется либо жертвовать памятью и делать кэширование всего и вся, плюс внедрять load-balancing сервера, либо переписывать с нуля на C++ c FastCGI. Возможно, Java-based фреймворки тоже могут с этим помочь, но здесь я немного отстал от жизни — в свое время (java1.4) все было еще совершенно не блеск.
AJAX-based сайты. Аякс прикручивается к чему угодно, спору нет. Однако стоимость этого прикручивания может взлететь очень высоко, если сайт будет чисто AJAX-based (как GMail). Ну эту тему мы уже вроде полностью раскрыли в ветке.
Интеграция с различными сервисами. Для примера возьму Kerberos-аутентификацию. В Python и Django встроенной поддержки кербероса нет, надо либо прикручивать через ctypes, либо искать внешние модули. В админке Django вообще все плохо с аутентификацией. В то же время в той же Java есть JAAS. Так что если предполагается тесная интеграция с внешними сервисами, надо этот вопрос сразу рассматривать.
Может есть что-то еще, сразу не скажу. Вообще, конечно, инструмент, а тем более фреймворк надо выбирать в соответствии с задачей. Однако в случае Python-а и Django нет ничего такого уж совсем запущенного, что на них нельзя было бы сделать. Но в принципе, это касается и всех других фреймворках. Правда у некоторых есть реально мозоли, которые надо знать заранее — например, огромное время холодного старта ASP.NET приложений. В Django ничего такого особо замечено не было. Так что глаза боятся, а руки делают — попробуйте, может вам и понравится
Здравствуйте, Nuald, Вы писали:
N>Производительность. На самом деле Django очень high-scaled фреймворк — то, что на нем крутится New Your Times и блог Медведева с реально ощутимым количеством хитов, о чем-нибудь да говорит. Но если все-таки писать что-то типа Twitter-а или Google-а, то надо тщательно проработь архитектуру. Python может стать очень узким местом, и придется либо жертвовать памятью и делать кэширование всего и вся, плюс внедрять load-balancing сервера, либо переписывать с нуля на C++ c FastCGI. Возможно, Java-based фреймворки тоже могут с этим помочь, но здесь я немного отстал от жизни — в свое время (java1.4) все было еще совершенно не блеск.
У меня максимум на миллион хитов в день рассчитывается. Так что Питон особо не будет напрягаться.
N>Интеграция с различными сервисами. Для примера возьму Kerberos-аутентификацию. В Python и Django встроенной поддержки кербероса нет, надо либо прикручивать через ctypes, либо искать внешние модули. В админке Django вообще все плохо с аутентификацией. В то же время в той же Java есть JAAS. Так что если предполагается тесная интеграция с внешними сервисами, надо этот вопрос сразу рассматривать.
Kerberos и авторизацию по сертефикатам я как раз собираюсь прикрутить Ничего там сложного быть не должно.
Здравствуйте, Cyberax, Вы писали:
C>Kerberos и авторизацию по сертефикатам я как раз собираюсь прикрутить Ничего там сложного быть не должно.
О-о-о, если прикрутишь, дай мне знать плиз (если конечно это не будет под NDA) Я у себя в блоге как раз про Kerberos писал, но вот поиски в области разработки приложений с его использованием много нарыть не удалось: Organizing Kerberos-based infrastructure
Здравствуйте, Nuald, Вы писали:
C>>Kerberos и авторизацию по сертефикатам я как раз собираюсь прикрутить Ничего там сложного быть не должно. N>О-о-о, если прикрутишь, дай мне знать плиз (если конечно это не будет под NDA)
В OpenSource выложу.
N>Я у себя в блоге как раз про Kerberos писал, но вот поиски в области разработки приложений с его использованием много нарыть не удалось: Organizing Kerberos-based infrastructure
Kerberos хоть сейчас можно с помощью Апача прикрутить, было бы желание (я даже находил в сети об этом упоминания).
PS: кстати, Win2k/XP прекрасно работают в обычном Kerberos-домене.
Здравствуйте, Cyberax, Вы писали:
C>Kerberos хоть сейчас можно с помощью Апача прикрутить, было бы желание (я даже находил в сети об этом упоминания).
Про апач я в курсе, я говорю про собственно веб-приложение. На уровне апача ты разруливаешь доступ, а скажем, что делать если у тебя логика приложения завязана на учетку? Т.е. например, в веб-приложении встроена авторизация, которая в зависимости от пользователя назначает ему нужную роль. Апач обеспечивает только аутентификацию. А веб-приложение должно взять kerberos-ticket, и из него вытащить всю нужную инфу.
C>PS: кстати, Win2k/XP прекрасно работают в обычном Kerberos-домене.
Т.е. ты хочешь сказать, если что у меня скажем поднят OpenLDAP+Samba+Kerberos, расшарены ресуры под самбой, и пользователь с винды находится в домене Kerberos-а, то сможет нормально зайти на расшаренный ресурс? Такое настроить можно, но насколько я помню, для этого домен должен быть поднят на самбе, а она уже сама коннектится к KAS. Если я не прав, то направь меня плиз в нужном направлении, а то ничего особо не смог найти. Конечно, еще остаются открытые вопросы по GPO и т.п., но мне это особо неинтересно — всегда можно в профиль пользователя добавить командный файл, который при логине будет отрабатываться и делать все необходимые манипуляции с реестром и файловой системой (насколько я знаю, GPO примерно так и работает).
Здравствуйте, Nuald, Вы писали:
C>>Kerberos хоть сейчас можно с помощью Апача прикрутить, было бы желание (я даже находил в сети об этом упоминания). N>Про апач я в курсе, я говорю про собственно веб-приложение. На уровне апача ты разруливаешь доступ, а скажем, что делать если у тебя логика приложения завязана на учетку? Т.е. например, в веб-приложении встроена авторизация, которая в зависимости от пользователя назначает ему нужную роль. Апач обеспечивает только аутентификацию. А веб-приложение должно взять kerberos-ticket, и из него вытащить всю нужную инфу.
Из krb-тикета ты особо ничего кроме принципала пользователя не возьмёшь, а его Apache тебе и так даст. А дальше уже используешь средства самого приложения для авторизации.
Единственная проблема, мне нужно будет поддерживать дальнейшее делегирование с помощью этого тикета, так что для меня прозрачная авторизация в Апаче не подойдёт.
C>>PS: кстати, Win2k/XP прекрасно работают в обычном Kerberos-домене. N>Т.е. ты хочешь сказать, если что у меня скажем поднят OpenLDAP+Samba+Kerberos, расшарены ресуры под самбой, и пользователь с винды находится в домене Kerberos-а, то сможет нормально зайти на расшаренный ресурс?
Да.
N>Такое настроить можно, но насколько я помню, для этого домен должен быть поднят на самбе, а она уже сама коннектится к KAS. Если я не прав, то направь меня плиз в нужном направлении, а то ничего особо не смог найти. Конечно, еще остаются открытые вопросы по GPO и т.п., но мне это особо неинтересно — всегда можно в профиль пользователя добавить командный файл, который при логине будет отрабатываться и делать все необходимые манипуляции с реестром и файловой системой (насколько я знаю, GPO примерно так и работает).
Ставишь Microsoft Resource Kit, там есть нужные утиллиты. Пользовался этим вот howto: http://www.upenn.edu/computing/pennkey/sysadmin/e_install_win/win-config.html
В ближайшем будущем можно на сервере поднять Samba4 — туда как раз на этой неделе добавляют полную поддержку LDAP-схемы ActiveDomain'а. Там вообще будет всё круто.
Здравствуйте, Cyberax, Вы писали:
C>Из krb-тикета ты особо ничего кроме принципала пользователя не возьмёшь, а его Apache тебе и так даст. А дальше уже используешь средства самого приложения для авторизации. C>Единственная проблема, мне нужно будет поддерживать дальнейшее делегирование с помощью этого тикета, так что для меня прозрачная авторизация в Апаче не подойдёт.
Гм, я читанул маны, и обнаружил, что в принципе все не так сложно, как кажется — у mod_auth_kerb есть опция KrbSaveCredentials, которая сохраняет тикет в кэш, а имя файла в переменную окружения KRB5CCNAME. Осталось только написать обертку на питоне, и все.
C>>>PS: кстати, Win2k/XP прекрасно работают в обычном Kerberos-домене. C>Ставишь Microsoft Resource Kit, там есть нужные утиллиты. Пользовался этим вот howto: http://www.upenn.edu/computing/pennkey/sysadmin/e_install_win/win-config.html
Не, я говорю про чисто Linux-based solution. Т.е. например, у нас есть такая проблема — виндами мы вообще не пользуемся, и только поднято некоторое количество виртуальных машин с клиентскими инсталляциями Windows. Они нам нужны исключительно для проверки работоспособности софта. Покупать Windows-сервер вообще смысла нет, т.к. на нем ничего крутить особо и ну будет. А домен хочется, т.к. хочется обеспечить SSO даже для немногочисленных инсталляций Windows.
C>В ближайшем будущем можно на сервере поднять Samba4 — туда как раз на этой неделе добавляют полную поддержку LDAP-схемы ActiveDomain'а. Там вообще будет всё круто.
Да, в курсе, все с нетерпением ждем
C>Но это уже лучше в другой форум идти.
Пусть модераторы выделят в отдельную ветку Ау, вы где?
Меня просто этот вопрос сильно интересует, но катастрофически не хватает времени, чтобы все настроить и поэкспериментировать. Вот тот же самый NuFW фаервол — вещь исключительно интересная, скачал LiveCD, в очередной раз возненавидел французов за их исключительно патриотическое отношение к своему языку, поигрался и забыл, т.к. больше времени не было. Поэтому хотелось бы пообщаться с тем, что имеет больше опыта в этом деле.
Здравствуйте, Nuald, Вы писали:
C>>Единственная проблема, мне нужно будет поддерживать дальнейшее делегирование с помощью этого тикета, так что для меня прозрачная авторизация в Апаче не подойдёт. N>Гм, я читанул маны, и обнаружил, что в принципе все не так сложно, как кажется — у mod_auth_kerb есть опция KrbSaveCredentials, которая сохраняет тикет в кэш, а имя файла в переменную окружения KRB5CCNAME. Осталось только написать обертку на питоне, и все.
Некрасиво. Кроме того, я всё под lighty хочу запускать. Не люблю Апач.
C>>Ставишь Microsoft Resource Kit, там есть нужные утиллиты. Пользовался этим вот howto: http://www.upenn.edu/computing/pennkey/sysadmin/e_install_win/win-config.html N>Не, я говорю про чисто Linux-based solution. Т.е. например, у нас есть такая проблема — виндами мы вообще не пользуемся, и только поднято некоторое количество виртуальных машин с клиентскими инсталляциями Windows. Они нам нужны исключительно для проверки работоспособности софта. Покупать Windows-сервер вообще смысла нет, т.к. на нем ничего крутить особо и ну будет.
Я про это и говорю. Ставишь Kerberos+LDAP, настраиваешь всё что тебе нужно на Линуксах. На клиентских Windows-машинах ставишь Resource Kit, там есть утиллита ksetup — с помощью неё уже настраиваешь вхождение в область Kerberos.
N>А домен хочется, т.к. хочется обеспечить SSO даже для немногочисленных инсталляций Windows.
Аналогично.
N>Пусть модераторы выделят в отдельную ветку Ау, вы где?
Не проснулись ещё. Не все же в Хабаровске
N>Меня просто этот вопрос сильно интересует, но катастрофически не хватает времени, чтобы все настроить и поэкспериментировать. Вот тот же самый NuFW фаервол — вещь исключительно интересная, скачал LiveCD, в очередной раз возненавидел французов за их исключительно патриотическое отношение к своему языку, поигрался и забыл, т.к. больше времени не было. Поэтому хотелось бы пообщаться с тем, что имеет больше опыта в этом деле.
Я занимаюсь всякими настройками, когда делать что-то нужное совсем лень.
Здравствуйте, Cyberax, Вы писали:
C>Некрасиво. Кроме того, я всё под lighty хочу запускать. Не люблю Апач.
Ты говоришь про lighttpd? А он разве поддерживает Kerberos?
C>Я про это и говорю. Ставишь Kerberos+LDAP, настраиваешь всё что тебе нужно на Линуксах. На клиентских Windows-машинах ставишь Resource Kit, там есть утиллита ksetup — с помощью неё уже настраиваешь вхождение в область Kerberos.
Ну ладно, Ajax пока у нас не приоритетный.
В частности нет автоматически генерируемой админки или даже просто форм, что заставляет писать лишний код. Условно я бы наверное его приравнял к Spring-у.
