My Red Hat Enterprise Edition 4 поставляется с Samba версии 3.0.10, в которой отсутствует поддержка атрибута «наследование владельца», необходимого для реализации общего ресурса Deny-Delete Write Once Read Many (например, выполните поиск в Google по запросу a-shared -drop-box-using-samba).
(Кстати, если кто-то знает альтернативный способ сделать это без обновления самбы, я все уши!)
Мне не так уж удобно строить из источника, и после часы поиска в Google (нет, у меня нет подписки на красную шляпу, поэтому я не могу просто запустить команду up2date), я обнаружил целую кучу rpms на http://ftp.sernet.de/pub/samba/tested/rhel/4/i386/ (Samba 3.2.15 для RHEL 4) ...
Далее я попробовал обновление их с rpm -U --nodeps команда, но я получил ошибки конфликта файлов. Итак, я пошел дальше и перезаписал все (по крайней мере, я так думал), используя rpm - сила вариант. Но ничего хорошего из этого не вышло. / usr / sbin / smbd -V по-прежнему возвращает старую версию.
На данный момент rpm -qa | grep samba возвращается,
samba3-client-3.2.15-40.el4
samba-3.0.10-1.4E.2
samba-client-3.0.10-1.4E.2
system-config-samba-1.2.21-1
samba3-3.2.15-40.el4
samba-common-3.0.10-1.4E.2
samba3-winbind-3.2.15-40.el4
Я не могу удалить старые, потому что
samba-common >= 3.0.8-0.pre1.3 is needed by (installed) gnome-vfs2-smb-2.8.2-8.2.x86_64
libsmbclient.so.0()(64bit) is needed by (installed) kdebase-3.3.1-5.8.x86_64
libsmbclient.so.0()(64bit) is needed by (installed) gnome-vfs2-smb-2.8.2-8.2.x86_64
Теперь это целая куча зависимостей, которых я не смею трогать :)
На этом этапе приветствуются любые указатели. Заранее спасибо!
Я бы не побоялся строить из исходного кода: это весело и полезно. Единственная большая проблема, с которой вы столкнетесь, - это та же проблема, с которой вы уже имея: зависимости. Чтобы обойти проблему зависимости, вам понадобится менеджер пакетов.
Хмммм. Вы можете установить Ням, это то, что вы получили бы в Fedora вместо up2date ... Он довольно хорошо справляется с зависимостями, а поиск в Google Yum, RHEL и Repository дает большое количество совпадений, поэтому есть репозитории, в которых будут построены RPM для вашей системы.
Если бы это был я, я бы, вероятно, пошел дальше и обновил KDE и Gnome, если бы было так важно установить более новую версию samba (на самом деле это ложь. Мне нравится командная строка, поэтому я бы просто пошел дальше и сломал кде и гном и не оглядывайся назад). Все дело в решении такого рода проблем с зависимостями.
Используйте сборки Samba из Enterprise Samba. Это сборки для конкретных дистрибутивов, и они очень надежны.
RPM созданы для разрешения зависимостей. Новые RPM Samba, которые вы нашли, были созданы для другой системы и скомпилированы для разных версий библиотек.
Вместо того, чтобы пытаться принудительно установить двоичные файлы, которые могут не работать с вашими системными библиотеками, вам следует создавайте свои собственные RPM и установите те. Найдите SRPM той версии Samba, которую вы хотите упростить, и прочитать несколько хороших руководств и книги чтобы понять процесс.
Плюсы:
Если у вас есть несколько компьютеров, использующих один и тот же дистрибутив, создание собственных локальных пакетов упрощает установку везде;
Вы избегаете нарушения зависимостей с другими системными пакетами.
У этого подхода есть несколько недостатков:
Это требует установки всех пакетов * -dev, необходимых для компиляции Samba (плюс все, что требуется для сборки SRPM);
Может потребоваться обновление некоторых зависимостей, чтобы заставить его скомпилировать (обычно с помощью того же процесса);
Он привносит в вашу систему потенциальные проблемы в виде программного обеспечения, которое не прошло тестирование вашего дистрибутива.
В качестве альтернативы вы можете получить tarball с исходным кодом для Samba, установить его в / usr / local и удалить все RPM Samba в пользу вашей скомпилированной версии. Но, как вы заметили, многие другие пакеты зависят от Samba, так что это целая банка червей. Создание собственных RPM и обновление намного удобнее, чем пытаться заставить RPM сохранять пакеты с отсутствующими зависимостями.
Хорошо, поэтому я наконец (по настоянию Satanicpuppy :) пошел дальше и оставил болтающиеся зависимости болтающимися. Это, по-видимому, решило проблему без каких-либо побочных эффектов, поэтому я публикую шаги здесь, потомки (я не принимаю ни один из ответов, потому что все они в некотором роде были правильными)
Dropbox работает так, как ожидалось от клиентов Windows, но Mac, похоже, это не нравится. Кажется, что макинтоши создают прокси-файл на SMB-сервере перед записью фактического файла. Поскольку я блокирую файл сразу после его создания (моя первоначальная цель заключалась в том, чтобы выполнить однократную запись и запретить удаление в поле сброса), это подавляет клиентов Mac, и они создают усеченные файлы с нулевым байтом.
В любом случае, большое спасибо всем, кто приложил усилия, чтобы помочь. Удачных вычислений!
Я решил обновить RHEL 5.4, установив libsmbclient-3.0.33, а после обновления я исключил libsmbclient.