* Re: [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12] @ 2009-07-20 10:49 ` Mykola S. Grechukh 2009-07-24 17:34 ` Evgeny Sinelnikov 0 siblings, 1 reply; 8+ messages in thread From: Mykola S. Grechukh @ 2009-07-20 10:49 UTC (permalink / raw) To: devel 2009/7/20 QA Team Robot <qa@altlinux.org>: > Package: tdb-1.0.6-alt3 > Status: Sisyphus/i586 test rebuild failed ффпечь ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12] 2009-07-20 10:49 ` [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12] Mykola S. Grechukh @ 2009-07-24 17:34 ` Evgeny Sinelnikov 2009-07-25 10:08 ` Alexander Bokovoy 0 siblings, 1 reply; 8+ messages in thread From: Evgeny Sinelnikov @ 2009-07-24 17:34 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 675 bytes --] 20 июля 2009 г. 14:49 пользователь Mykola S. Grechukh (gns@altlinux.org) написал: > 2009/7/20 QA Team Robot <qa@altlinux.org>: >> Package: tdb-1.0.6-alt3 >> Status: Sisyphus/i586 test rebuild failed > > > ффпечь Таким образом, путь для выкладывания libtdb и libtalloc от samba4 открыт. Прошу конструктивно указать на препятствия и проблемы, которые есть в текущих сборках Fedora в этом плане, и чем это грозит нам в текущих условиях. "О, ужас, ужас, ужас..." - это не совсем понятно :) Для большей ясности прикладываю diff'ы для libtdb и libtalloc между samba-3.4.0 и samba-4.0.0alpha8. Прошу заметить, что критической разницы в ABI там нет. -- Sin (Sinelnikov Evgeny) [-- Attachment #2: tdb-v4alpha8.diff.gz --] [-- Type: application/x-gzip, Size: 15365 bytes --] [-- Attachment #3: talloc-v4alpha8.diff.gz --] [-- Type: application/x-gzip, Size: 11632 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12] 2009-07-24 17:34 ` Evgeny Sinelnikov @ 2009-07-25 10:08 ` Alexander Bokovoy 2009-07-26 19:23 ` Evgeny Sinelnikov 0 siblings, 1 reply; 8+ messages in thread From: Alexander Bokovoy @ 2009-07-25 10:08 UTC (permalink / raw) To: ALT Linux Team development discussions 2009/7/24 Evgeny Sinelnikov <sin@altlinux.ru>: > 20 июля 2009 г. 14:49 пользователь Mykola S. Grechukh > (gns@altlinux.org) написал: >> 2009/7/20 QA Team Robot <qa@altlinux.org>: >>> Package: tdb-1.0.6-alt3 >>> Status: Sisyphus/i586 test rebuild failed >> >> >> ффпечь > > Таким образом, путь для выкладывания libtdb и libtalloc от samba4 открыт. > > Прошу конструктивно указать на препятствия и проблемы, которые есть в > текущих сборках Fedora в этом плане, и чем это грозит нам в текущих > условиях. "О, ужас, ужас, ужас..." - это не совсем понятно :) > > Для большей ясности прикладываю diff'ы для libtdb и libtalloc между > samba-3.4.0 и samba-4.0.0alpha8. Прошу заметить, что критической > разницы в ABI там нет. Проблема, которую я вижу, состоит в том, что мы будем делать с применением результатов той самой дискуссии в samba-technical@. По git diff release-4-0-0alpha8 HEAD -- lib/talloc и git diff release-3-4-0 HEAD -- lib/talloc можно видеть, что изменения в API и ABI существенные. Если мы сейчас запакуем "не master", то будет необходимо решать эту проблему при следующей сборке -- когда выйдет либо очередная альфа 4.0, либо релиз 3.5, что будет гораздо сложнее, потому что в тот момент придется снова согласовывать сборки. Поскольку предыдущая дискуссия в devel@ продемонстрировала, что в Сизифе все равно не верят в стабильность сборок Самбы, то я предлагаю поступить следующим образом: 1. Собрать 4.0 и 3.4+ в том виде, как оно есть сейчас в master, не решая проблемы обновления в пост-установочных скриптах. Бинарные пакеты будут иметь имена samba3 и samba4, пакет samba-* исчезнет. Установка samba3-* будет приводить к сносу samba-* с бэкапом имеющихся настроек samba-* в определенное место. 2. Создать пакет samba-migration, который бы мигрировал настройки, созданные бэкапом, в новые насколько это возможно. 3. Добавить поддержку миграции в samba3 на основе samba-migration. Таким образом, в Сизифе некоторое время будет разломана Самба в смысле переноса старых настроек и ожиданий конфигуратора. Также надо будет пересобрать несколько пакетов, которые используют libsmbclient, поскольку ABI изменится. -- / Alexander Bokovoy ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12] 2009-07-25 10:08 ` Alexander Bokovoy @ 2009-07-26 19:23 ` Evgeny Sinelnikov 2009-07-26 20:08 ` Alexander Bokovoy 0 siblings, 1 reply; 8+ messages in thread From: Evgeny Sinelnikov @ 2009-07-26 19:23 UTC (permalink / raw) To: ALT Linux Team development discussions 25 июля 2009 г. 14:08 пользователь Alexander Bokovoy (ab@altlinux.org) написал: > 2009/7/24 Evgeny Sinelnikov <sin@altlinux.ru>: >> 20 июля 2009 г. 14:49 пользователь Mykola S. Grechukh >> (gns@altlinux.org) написал: >>> 2009/7/20 QA Team Robot <qa@altlinux.org>: >>>> Package: tdb-1.0.6-alt3 >>>> Status: Sisyphus/i586 test rebuild failed >>> >>> >>> ффпечь >> >> Таким образом, путь для выкладывания libtdb и libtalloc от samba4 открыт. >> >> Прошу конструктивно указать на препятствия и проблемы, которые есть в >> текущих сборках Fedora в этом плане, и чем это грозит нам в текущих >> условиях. "О, ужас, ужас, ужас..." - это не совсем понятно :) >> >> Для большей ясности прикладываю diff'ы для libtdb и libtalloc между >> samba-3.4.0 и samba-4.0.0alpha8. Прошу заметить, что критической >> разницы в ABI там нет. > Проблема, которую я вижу, состоит в том, что мы будем делать с > применением результатов той самой дискуссии в samba-technical@. По git > diff release-4-0-0alpha8 HEAD -- lib/talloc и git diff release-3-4-0 > HEAD -- lib/talloc можно видеть, что изменения в API и ABI > существенные. Я прислал два дифа для lib/talloc и lib/tdb - как раз для git diff release-4-0-0alpha8 HEAD (4ceae35d7eb3b7e2e38f226e39853cff40d92464 - ветка v4-0-stable) и git diff release-3-4-0 (51b334e2d9739abc748490f6085ed8b8e5e1f4b4 - ветка v3-4-stable) Репозиторий git://git.samba.org/samba.git По этим дифам видно, что ABI и API критичных различий _не_ имеют. В связи с этим сборка в Fedora выглядит вполне правомерно. Я не там смотрю? Почему я вижу отсутствие разницы, а вы говорите о существенных различиях? Давайте посмотрим... Разница для talloc: diff -Nur talloc-v3.4/talloc.h talloc-v4alpha8/talloc.h --- talloc-v3.4/talloc.h 2009-07-03 15:21:14 +0400 +++ talloc-v4alpha8/talloc.h 2009-07-09 18:46:46 +0400 @@ -121,7 +121,7 @@ /* The following definitions come from talloc.c */ void *_talloc(const void *context, size_t size); void *talloc_pool(const void *context, size_t size); -void _talloc_set_destructor(const void *ptr, int (*destructor)(void *)); +void _talloc_set_destructor(const void *ptr, int (*_destructor)(void *)); int talloc_increase_ref_count(const void *ptr); size_t talloc_reference_count(const void *ptr); void *_talloc_reference(const void *context, const void *ptr); diff -Nur talloc-v3.4/talloc.c talloc-v4alpha8/talloc.c --- talloc-v3.4/talloc.c 2009-07-03 15:21:14 +0400 +++ talloc-v4alpha8/talloc.c 2009-07-09 18:46:46 +0400 @@ -1008,6 +1008,11 @@ return NULL; } + /* don't let anybody try to realloc a talloc_pool */ + if (unlikely(tc->flags & TALLOC_FLAG_POOL)) { + return NULL; + } + /* don't shrink if we have less than 1k to gain */ if ((size < tc->size) && ((tc->size - size) < 1024)) { tc->size = size; Разница для tdb, чуть побольше... diff -Nur tdb-v3.4/include/tdb.h tdb-v4alpha8/include/tdb.h --- tdb-v3.4/include/tdb.h 2009-07-03 15:21:14 +0400 +++ tdb-v4alpha8/include/tdb.h 2009-07-09 18:46:46 +0400 @@ -129,6 +129,7 @@ tdb_log_func tdb_log_fn(struct tdb_context *tdb); void *tdb_get_logging_private(struct tdb_context *tdb); int tdb_transaction_start(struct tdb_context *tdb); +int tdb_transaction_prepare_commit(struct tdb_context *tdb); int tdb_transaction_commit(struct tdb_context *tdb); int tdb_transaction_cancel(struct tdb_context *tdb); int tdb_transaction_recover(struct tdb_context *tdb); --- tdb-v3.4/docs/README 2009-07-03 15:21:14 +0400 +++ tdb-v4alpha8/docs/README 2009-07-09 18:46:46 +0400 @@ -236,3 +236,11 @@ commit a current transaction, updating the database and releasing the transaction locks. . +---------------------------------------------------------------------- +int tdb_transaction_prepare_commit(TDB_CONTEXT *tdb) + + prepare to commit a current transaction, for two-phase commits. + Once prepared for commit, the only allowed calls are + tdb_transaction_commit() or tdb_transaction_cancel(). Preparing + allocates disk space for the pending updates, so a subsequent + commit should succeed (barring any hardware failures). в файле transaction.c добавлена соответствующая функциональность. В master'е для tdb добавлена косметика. Для talloc изменения действительно есть... Но если ждать 3.5, то его можно всё время ждать и вообще ничего не паковать... Причём я не вижу разницы для 4.0 и 3.4 сейчас - они идут в ногу... Это снова разговор о будущем... Объясните мне, пожалуйста, где эта существенная разница. Может у меня нет тот репозиторий? > Если мы сейчас запакуем "не master", то будет необходимо > решать эту проблему при следующей сборке -- когда выйдет либо > очередная альфа 4.0, либо релиз 3.5, что будет гораздо сложнее, потому > что в тот момент придется снова согласовывать сборки. Да, и решать эту проблему можно жёсткой зависимостью на версию. Понимаете, ни в одной стабильной ветке этим новым API talloc ещё не пахнет. И пока мы с вами рассуждаем, на счёт будущих проблем, в Fedora этим уже пользуются... И завтра, когда будет новое API, тоже будут пользоваться... К чему вести речь о коде из master'а, если он отсутствует в обоих стабильных ветках? Это же забалтывание проблемы. Сейчас можно запаковать 3.4 и 4.0, а там тех существенных отличий, о которых идёт речь нет. > Поскольку предыдущая дискуссия в devel@ продемонстрировала, что в > Сизифе все равно не верят в стабильность сборок Самбы, то я предлагаю > поступить следующим образом: > 1. Собрать 4.0 и 3.4+ в том виде, как оно есть сейчас в master, не > решая проблемы обновления в пост-установочных скриптах. Бинарные > пакеты будут иметь имена samba3 и samba4, пакет samba-* исчезнет. > Установка samba3-* будет приводить к сносу samba-* с бэкапом имеющихся > настроек samba-* в определенное место. > 2. Создать пакет samba-migration, который бы мигрировал настройки, > созданные бэкапом, в новые насколько это возможно. > 3. Добавить поддержку миграции в samba3 на основе samba-migration. Здесь не сказано про общие библиотеки, которые должны сходится. Давайте определимся. Я считаю, стоит придерживаться подхода выбранного в Fedora, когда общие либы буду выделены в отдельные пакеты... Два вида библиотек быть не должно... Иначе это чревато другими проблемами... Когда одна либа слинкована с libtalloc-samba3, другая - с libtalloc-samba4, а приложение с этими двумя... Подход с двумя либами - это не решение. > Таким образом, в Сизифе некоторое время будет разломана Самба в смысле > переноса старых настроек и ожиданий конфигуратора. Также надо будет > пересобрать несколько пакетов, которые используют libsmbclient, > поскольку ABI изменится. Я полагаю, что "ломание" самбы - это префекционисткая мера, которая нужна нескольким процентам пользователей, которые используют самбу совместно с тесной интеграцией с AD. Для большинства пользователей Сизифа эта проблема решается удалением старых баз от самбы. Вот и вся миграция. Кроме как гостя и системных пользователей у нас обычно никого не используют... Для тех же кому это миграция нужна сидеть на Сизифе не рекомендуется... Я бы предложил вместо ломания сделать после обновления автоматический бекап в специально выделенное место. Далее, написанный, в будущем, мигратор позволит восстанавливать базы до тех пор пока они нормально не восстановятся... Такой подход позволит обновить самбу ничего не ломая. -- Sin (Sinelnikov Evgeny) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12] 2009-07-26 19:23 ` Evgeny Sinelnikov @ 2009-07-26 20:08 ` Alexander Bokovoy 2009-07-26 21:29 ` Evgeny Sinelnikov 0 siblings, 1 reply; 8+ messages in thread From: Alexander Bokovoy @ 2009-07-26 20:08 UTC (permalink / raw) To: ALT Linux Team development discussions 2009/7/26 Evgeny Sinelnikov <sin@altlinux.ru>: > По этим дифам видно, что ABI и API критичных различий _не_ имеют. В > связи с этим сборка в Fedora выглядит вполне правомерно. > > Я не там смотрю? Почему я вижу отсутствие разницы, а вы говорите о > существенных различиях? Вы не туда смотрели. > Давайте посмотрим... Разница для talloc: > > diff -Nur talloc-v3.4/talloc.h talloc-v4alpha8/talloc.h Как я сказал -- смотреть надо в разницу между master и этими стабильными ветками. Вся суть дискуссии была именно в этом. > Объясните мне, пожалуйста, где эта существенная разница. Может у меня > нет тот репозиторий? Вы читали дискуссию в samba-technical@, на которую сами же и ссылались? >> Если мы сейчас запакуем "не master", то будет необходимо >> решать эту проблему при следующей сборке -- когда выйдет либо >> очередная альфа 4.0, либо релиз 3.5, что будет гораздо сложнее, потому >> что в тот момент придется снова согласовывать сборки. > > Да, и решать эту проблему можно жёсткой зависимостью на версию. > Понимаете, ни в одной стабильной ветке этим новым API talloc ещё не > пахнет. И пока мы с вами рассуждаем, на счёт будущих проблем, в Fedora > этим уже пользуются... И завтра, когда будет новое API, тоже будут > пользоваться... Я говорю о том, что уже есть и то, с чем придется иметь дело. Задача мейнтейнера -- обеспечить минимальные проблемы для своих пользователей. Двойной переезд за короткое время, который Вы предлагаете, таким свойством не обладает. > Здесь не сказано про общие библиотеки, которые должны сходится. > Давайте определимся. Я считаю, стоит придерживаться подхода выбранного > в Fedora, когда общие либы буду выделены в отдельные пакеты... > > Два вида библиотек быть не должно... Иначе это чревато другими > проблемами... Когда одна либа слинкована с libtalloc-samba3, другая - > с libtalloc-samba4, а приложение с этими двумя... Подход с двумя > либами - это не решение. О двух библиотеках я речь и не вел, перечитайте мое предложение. Я вообще не говорю сейчас о двух библиотеках, я веду речь о сборке master, в котором source4 и source3 используют единые версии служебных библиотек. >> Таким образом, в Сизифе некоторое время будет разломана Самба в смысле >> переноса старых настроек и ожиданий конфигуратора. Также надо будет >> пересобрать несколько пакетов, которые используют libsmbclient, >> поскольку ABI изменится. > > Я полагаю, что "ломание" самбы - это префекционисткая мера, которая > нужна нескольким процентам пользователей, которые используют самбу > совместно с тесной интеграцией с AD. Для большинства пользователей > Сизифа эта проблема решается удалением старых баз от самбы. Вот и вся > миграция. Кроме как гостя и системных пользователей у нас обычно > никого не используют... Я полагаю, что у меня достаточно оснований говорить то, о чем я говорю, в том числе и на основании пользовательских отчетов. У меня складывается впечатление, что Вы хотите видеть в Сизифе определенное ПО и вам не очень близки интересы пользователей. Я не хочу в очередной раз обсуждать проблему фактического отсутствия стабильных репозитариев и того, что пользователи реально сидят на Сизифе вместо них. Это не имеет отношения к нашим баранам. К ним имеет отношение то, что такая ситуация есть и поэтому просто "сносить" существующие конфигурации, опираясь на личные ощущения. Я пока не готов разменивать осторожный подход к данным пользователей на сборку без оглядки. > Для тех же кому это миграция нужна сидеть на Сизифе не > рекомендуется... Я бы предложил вместо ломания сделать после > обновления автоматический бекап в специально выделенное место. Далее, > написанный, в будущем, мигратор позволит восстанавливать базы до тех > пор пока они нормально не восстановятся... > > Такой подход позволит обновить самбу ничего не ломая. Если хотите помочь, напишите такой автоматический бэкап и восстановление из него для 3.0 -> 3.4. -- / Alexander Bokovoy ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12] 2009-07-26 20:08 ` Alexander Bokovoy @ 2009-07-26 21:29 ` Evgeny Sinelnikov 2009-07-27 4:08 ` Alexander Bokovoy 0 siblings, 1 reply; 8+ messages in thread From: Evgeny Sinelnikov @ 2009-07-26 21:29 UTC (permalink / raw) To: ALT Linux Team development discussions 2ab@:Читайте последовательно, моё осознание вашего предложения протекало постепенно, по мере прочтения вашего ответа... ;) 27 июля 2009 г. 0:08 пользователь Alexander Bokovoy (ab@altlinux.org) написал: > 2009/7/26 Evgeny Sinelnikov <sin@altlinux.ru>: >> По этим дифам видно, что ABI и API критичных различий _не_ имеют. В >> связи с этим сборка в Fedora выглядит вполне правомерно. >> >> Я не там смотрю? Почему я вижу отсутствие разницы, а вы говорите о >> существенных различиях? > Вы не туда смотрели. Ответ не совсем конструктивен... Я спрашивал, куда смотреть? >> Давайте посмотрим... Разница для talloc: >> >> diff -Nur talloc-v3.4/talloc.h talloc-v4alpha8/talloc.h > Как я сказал -- смотреть надо в разницу между master и этими > стабильными ветками. Вся суть дискуссии была именно в этом. Я не совсем понимаю необходимости смотреть на разницу между тем, "что есть" и тем, "что будет", с задаче запаковать "то, что есть". А именно. 4.0alpha8 и 3.4.0. Я искренне полагаю, что вы усложняете задачу этим сравнением. К чему решать вопросы, с которыми upstream ещё не определился? Сегодня и завтра оно работать будет... К тому же, если вопрос не в библиотеках, то в чём собственно предложение? Сейчас можно собрать то, что есть... >> Объясните мне, пожалуйста, где эта существенная разница. Может у меня >> нет тот репозиторий? > Вы читали дискуссию в samba-technical@, на которую сами же и ссылались? Да, но я никак не могу добиться какую часть из этой большой и длительной дискуссии вы приводите в качестве аргументов, а самое главное, аргументов для чего... Я не понимаю сути вопроса по сравнению master и того, "что есть" (samba4.0 и samba3.4). Когда для сборки важно соответствие того, "что есть" (samba4.0) и того, "что есть" (samba3.4). > >>> Если мы сейчас запакуем "не master", то будет необходимо >>> решать эту проблему при следующей сборке -- когда выйдет либо >>> очередная альфа 4.0, либо релиз 3.5, что будет гораздо сложнее, потому >>> что в тот момент придется снова согласовывать сборки. >> >> Да, и решать эту проблему можно жёсткой зависимостью на версию. >> Понимаете, ни в одной стабильной ветке этим новым API talloc ещё не >> пахнет. И пока мы с вами рассуждаем, на счёт будущих проблем, в Fedora >> этим уже пользуются... И завтра, когда будет новое API, тоже будут >> пользоваться... > Я говорю о том, что уже есть и то, с чем придется иметь дело. Задача > мейнтейнера -- обеспечить минимальные проблемы для своих > пользователей. Двойной переезд за короткое время, который Вы > предлагаете, таким свойством не обладает. По моему, вы путаете "пользователей", которые будут устанавливать и запускать пакеты, с "пользователями", которые будут самостоятельно компилировать приложения с библиотеками от самбы. Первых обеспечить безопасным переездом будет можно, вторых - нет. Но кто эти вторые? Человек, который использует библиотеку с нестабильным API, он должен быть к этому готов. Я вообще не понимаю вашего предложения на этот счёт. Неужели вы предлагаете вместо того, чтобы собрать стабильные выпуски Samba, "похачить" их на предмет совместимости с будущей версией их же внутренних библиотек, дабы чего-то избежать? >> Здесь не сказано про общие библиотеки, которые должны сходится. >> Давайте определимся. Я считаю, стоит придерживаться подхода выбранного >> в Fedora, когда общие либы буду выделены в отдельные пакеты... >> >> Два вида библиотек быть не должно... Иначе это чревато другими >> проблемами... Когда одна либа слинкована с libtalloc-samba3, другая - >> с libtalloc-samba4, а приложение с этими двумя... Подход с двумя >> либами - это не решение. > О двух библиотеках я речь и не вел, перечитайте мое предложение. Я > вообще не говорю сейчас о двух библиотеках, я веду речь о сборке > master, в котором source4 и source3 используют единые версии служебных > библиотек. > То есть совсем про master? Честное слово, я удивлён... Действительно интерпретировать "Собрать 4.0 и 3.4+ в том виде, как оно есть сейчас в master" можно по разному... Я полагал, что вы имеете в виду текущие срезы и обновления у к ним... >>> Таким образом, в Сизифе некоторое время будет разломана Самба в смысле >>> переноса старых настроек и ожиданий конфигуратора. Также надо будет >>> пересобрать несколько пакетов, которые используют libsmbclient, >>> поскольку ABI изменится. >> >> Я полагаю, что "ломание" самбы - это префекционисткая мера, которая >> нужна нескольким процентам пользователей, которые используют самбу >> совместно с тесной интеграцией с AD. Для большинства пользователей >> Сизифа эта проблема решается удалением старых баз от самбы. Вот и вся >> миграция. Кроме как гостя и системных пользователей у нас обычно >> никого не используют... > Я полагаю, что у меня достаточно оснований говорить то, о чем я > говорю, в том числе и на основании пользовательских отчетов. Хорошо, я спорить здесь не могу... Вероятно, я не понимаю всех вариантов проблем. > У меня складывается впечатление, что Вы хотите видеть в Сизифе > определенное ПО и вам не очень близки интересы пользователей. Я не > хочу в очередной раз обсуждать проблему фактического отсутствия > стабильных репозитариев и того, что пользователи реально сидят на > Сизифе вместо них. Это не имеет отношения к нашим баранам. К ним имеет > отношение то, что такая ситуация есть и поэтому просто "сносить" > существующие конфигурации, опираясь на личные ощущения. Я ощущаю некоторые противоречия в ваших предложениях. С одной стороны вы говорите о пользователях, с другой - подразумеваете разработчиков. С одной стороны заявляете о том, что "предыдущая дискуссия в devel@ продемонстрировала, что в Сизифе все равно не верят в стабильность сборок Самбы", с другой - "не готовы разменивать осторожный подход к определённым пользователям". > Я пока не готов разменивать осторожный подход к данным пользователей > на сборку без оглядки. В итоге, я не понимаю какого же компромисса мы хотим добиться. Я готов принять "почти" любой :) Но я хочу его понять и не тянуть с этим долго ;) >> Для тех же кому это миграция нужна сидеть на Сизифе не >> рекомендуется... Я бы предложил вместо ломания сделать после >> обновления автоматический бекап в специально выделенное место. Далее, >> написанный, в будущем, мигратор позволит восстанавливать базы до тех >> пор пока они нормально не восстановятся... >> >> Такой подход позволит обновить самбу ничего не ломая. > Если хотите помочь, напишите такой автоматический бэкап и > восстановление из него для 3.0 -> 3.4. На деле я предложил то же самое, что и вы, только другими словами. Только для вас вариант слетевших баз - это сломанная самба, а я не вижу в этом ничего плохого, для большинства пользователей... Везде, где у меня используется интеграция с доменом, я не поднимался выше 5.0. Так, что ваш вариант, если я его теперь правильно осознаю, я поддерживаю... Резюмируя, своими словами, я понял вас так. - Собираем самбу из master (то есть из самого распоследнего git'а разработчиков), в котором сливаются samba3 и samba4. - Делаем это так, что получаем две самбы. - Настройки разносим так, чтобы у новых сборок они были в новых местах, тем самым обеспечивая пресловутый бекап для миграции. Мне нравится это вариант. Но, я как-то полагаю, что обеспечить сборку 4.0.0alpha8 и 3.4.0 можно сегодня-завтра. А этот красивый вариант мы ещё до осени пилить будем, если не определимся с минимальным результатом... При этом, если результат будет слишком минимальным, стабильность этого варианта, для меня, выглядит намного более сомнительной, чем миграция. Возможно мои опасения излишни... Как вы предлагаете это собирать и тестировать? Собираем из одного git'а обе самбы в одном спеке? Как поступаем с клиентскими библиотеками? -- Sin (Sinelnikov Evgeny) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12] 2009-07-26 21:29 ` Evgeny Sinelnikov @ 2009-07-27 4:08 ` Alexander Bokovoy 2009-07-27 6:28 ` Evgeny Sinelnikov 0 siblings, 1 reply; 8+ messages in thread From: Alexander Bokovoy @ 2009-07-27 4:08 UTC (permalink / raw) To: ALT Linux Team development discussions 2009/7/27 Evgeny Sinelnikov <sin@altlinux.ru>: > На деле я предложил то же самое, что и вы, только другими словами. > Только для вас вариант слетевших баз - это сломанная самба, а я не > вижу в этом ничего плохого, для большинства пользователей... Везде, > где у меня используется интеграция с доменом, я не поднимался выше > 5.0. Если учетные записи, в том числе и машин, вдруг "исчезнут", пользователям (администраторам) будет абсолютно все равно, какая версия Самбы приехала в виде обновления. Заведение этих пользователей (если Самба использовалась как контроллер домена даже в самом простом варианте с tdbsam или smbpasswd) влечет за собой организационные проблемы в виде действий пользователей по вводу паролей в очередной раз и по перевводу рабочих станций обратно в домен. Это довольно трудоемкая организационная процедура, когда системой пользуются даже несколько десятков пользователей, не говоря уже о сотнях. В случае LDAP все немного проще, но и здесь переезд означает смену конфигурационного файла (idmap config alloc backend и тому подобное). > Так, что ваш вариант, если я его теперь правильно осознаю, я поддерживаю... > Резюмируя, своими словами, я понял вас так. > - Собираем самбу из master (то есть из самого распоследнего git'а > разработчиков), в котором сливаются samba3 и samba4. > - Делаем это так, что получаем две самбы. > - Настройки разносим так, чтобы у новых сборок они были в новых > местах, тем самым обеспечивая пресловутый бекап для миграции. Да. > Возможно мои опасения излишни... Как вы предлагаете это собирать и тестировать? > Собираем из одного git'а обе самбы в одном спеке? Собираем из одного git-а двумя спеками -- по разным тэгам. Приоритет при сборке не важен, нужно определиться с чем-то одним, что будет содержать libtdb, libtalloc, libtevent. Остальное собирается с ними как с системными. Можно даже собирать их отдельным спеком (все три основных библиотеки вместе). Напомню, что все это gear позволяет организовать. > Как поступаем с клиентскими библиотеками? Клиентские библиотеки в 3.х и 4.х различаются, они даже по именам не пересекаются. Аналога libsmbclient в 4.0 нет, libcli более низкоуровневая. С остальными немного проще. -- / Alexander Bokovoy ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12] 2009-07-27 4:08 ` Alexander Bokovoy @ 2009-07-27 6:28 ` Evgeny Sinelnikov 0 siblings, 0 replies; 8+ messages in thread From: Evgeny Sinelnikov @ 2009-07-27 6:28 UTC (permalink / raw) To: ALT Linux Team development discussions 27 июля 2009 г. 8:08 пользователь Alexander Bokovoy (ab@altlinux.org) написал: > 2009/7/27 Evgeny Sinelnikov <sin@altlinux.ru>: >> На деле я предложил то же самое, что и вы, только другими словами. >> Только для вас вариант слетевших баз - это сломанная самба, а я не >> вижу в этом ничего плохого, для большинства пользователей... Везде, >> где у меня используется интеграция с доменом, я не поднимался выше >> 5.0. > Если учетные записи, в том числе и машин, вдруг "исчезнут", > пользователям (администраторам) будет абсолютно все равно, какая > версия Самбы приехала в виде обновления. Заведение этих пользователей > (если Самба использовалась как контроллер домена даже в самом простом > варианте с tdbsam или smbpasswd) влечет за собой организационные > проблемы в виде действий пользователей по вводу паролей в очередной > раз и по перевводу рабочих станций обратно в домен. Это довольно > трудоемкая организационная процедура, когда системой пользуются даже > несколько десятков пользователей, не говоря уже о сотнях. Это безусловно плохо... Но решать вопрос иначе, чем поэтапно, мне кажется довольно сложно. Наши средства совместной разработки не приспособлены к такой коллективной работе, которая бы не требовала "перепрыгивать пропасть в два и более прыжков..." Всё, что мы себе можем позволить - это плодить бранчи. А, в текущем workflow, это чревато поддержкой их всех по цепочке из-за особенностей обновления. Последнее для сборки приспособлено, а вот, для тестирования, аналогичной штуки, которую привёл в недавнем сообщении mike@ (что-то вроде btrfs на руте для откатов системы) у нас пока не практикуется. > В случае LDAP все немного проще, но и здесь переезд означает смену > конфигурационного файла (idmap config alloc backend и тому подобное). В случае же Samba нужно сначала ручной способ обнаружить... У меня, на первый взгляд, сложилось впечатление, что этот процесс не особо описан... Даже здесь: http://samba.org/samba/docs/man/Samba-HOWTO-Collection/upgrading-to-3.0.html довольно не густо. Чтобы написать мигратор, нужно понимать, а что же должно переехать. У кого-нибудь есть опыт переезда? >> Так, что ваш вариант, если я его теперь правильно осознаю, я поддерживаю... >> Резюмируя, своими словами, я понял вас так. >> - Собираем самбу из master (то есть из самого распоследнего git'а >> разработчиков), в котором сливаются samba3 и samba4. >> - Делаем это так, что получаем две самбы. >> - Настройки разносим так, чтобы у новых сборок они были в новых >> местах, тем самым обеспечивая пресловутый бекап для миграции. > Да. > >> Возможно мои опасения излишни... Как вы предлагаете это собирать и тестировать? >> Собираем из одного git'а обе самбы в одном спеке? > Собираем из одного git-а двумя спеками -- по разным тэгам. Приоритет > при сборке не важен, нужно определиться с чем-то одним, что будет > содержать libtdb, libtalloc, libtevent. Остальное собирается с ними > как с системными. Можно даже собирать их отдельным спеком (все три > основных библиотеки вместе). Напомню, что все это gear позволяет > организовать. Да, полагаю, что либы можно отдельными тегами... Но вы не перечислили ещё одну довольнo не простую деталь - libldb. В случае с samba4 сборка модулей для libldb сделана довольно странно..Сборка модулей в so не завершена, вместо этого они линкуются во все нужные бинарники статиком. В итоге питоновские модули из каталога сборки работают, а из установленной системы - нет. Полагаю, что собирать есть смысл только liblbdb от samba4 - на его API завязаны другие проекты. >> Как поступаем с клиентскими библиотеками? > Клиентские библиотеки в 3.х и 4.х различаются, они даже по именам не > пересекаются. Аналога libsmbclient в 4.0 нет, libcli более > низкоуровневая. С остальными немного проще. > Ну, тогда осталось отделить внутренние библиотеки от клиентских. Вот это у нас куда пойдёт? %_libdir/libdcerpc.so.* %_libdir/libdcerpc_samr.so.* %_libdir/libndr.so.* %_libdir/libsamba-hostconfig.so.* %_libdir/libsamba-util.so.* Для него ведь и devel есть. Winbind'ов два разных планируем? Samba-common каким планируем? -- Sin (Sinelnikov Evgeny) ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-07-27 6:28 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-07-20 10:49 ` [devel] tdb-1.0.6-alt3: Sisyphus/i586 test rebuild failed [12] Mykola S. Grechukh 2009-07-24 17:34 ` Evgeny Sinelnikov 2009-07-25 10:08 ` Alexander Bokovoy 2009-07-26 19:23 ` Evgeny Sinelnikov 2009-07-26 20:08 ` Alexander Bokovoy 2009-07-26 21:29 ` Evgeny Sinelnikov 2009-07-27 4:08 ` Alexander Bokovoy 2009-07-27 6:28 ` Evgeny Sinelnikov
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git