Кстати, в гитхабе все задачки по 5 и 6 были закрыты чуть ли не лично Тимом первого июля. Типа поддержка всё, но закрыты были не с мотивировкой вонтду или чем-то аналогичным, а как исправленные. Свинство.

Здрастуйте.
Подскажите как уменьшить размер папки log, разрослась на 40 гиг.

Если хотите сохранить внутреннюю статистику и позможность её перестройки, то /dspace/log или оставить как есть, или сжимать средствами ФС.

У меня есть инстанс где /dspace/log весит 1.5ТБ

Для пользователей, использующих dspace 5.8 и ниже (только для 5 версии)
Чтобы обновить файлик GeoLityCity.dat для статистики, можно воспользоваться ресурсом по адресу
geoip-legacy/
Файл GeoIPCity.dat.gz.
Для распаковки в Linux использовать команду

gzip -dc GeoIPCity.dat.gz > /dspace/config/GeoIPCity.dat

Они пытались...
[wiki.lyrasis.org]

Но на самом деле и dat и mmdb - это прикладывание подорожника. Половина "клиентов" используют арендные адреса, не привязанные явно к географии. Этот функционал пойдёт вслед за dspace stats-util -u :)

Но с 5.8 обновиться бы... там есть всякие неприятные штуки и в xmlui и в jspui.

[ideafix.su] - с высокой вероятностью делать этого не нужно, но с одной стороны, много где есть приказ от коллег по ИБ закрывать всё обнаруженное, а с другой стороны, хуже не будет.

Доброго времени суток!

Возникла необходимость заблокировать доступ к определенной коллекции для определенного диапазона ip-адресов. Возможно ли это сделать на уровне tomkat? Может кто-то делал подобное?

Спасибо!

На уровне Tomcat это едва ли возможно, разве что Вы перечислите в правиле ВСЕ хендлы и коллекции и документов.

Мне приходит на ум что-то типа:

<Context path="/bitstream/123456789/1/*|/bitstream/123456789/2/*|/bitstream/123456789/3/*" ...>
<Valve className="org.apache.catalina.valves.RemoteAddrValve" deny="11\.2\.3\.4|5\.6\..*" />
</Context>

Где context path это регексп с адресами, а в параметре deny указан один адрес и одна подсеть.

Но может лучше реализовать авторизацию по IP на уровне dspace или пришло время поставить перед томкетом nginx или apache httpd?

Добрый день, коллеги!

По производственной необходимости и спортивному интересу, стал осваивать DSpace 7.6.1. для создания библиотеки по узкой медицинской теме. Сначала для собственных нужнд, в дальнейшем возможно расширение на паблик.

За два месяца экспериментов, поиска инструкция, составления своего гайда по установке, более-менее пришло осознание как это работает, но осталось много вопросов по тонким настройкам, а именно:
1. Solr "из коробки" насколько хорошо работает по русским словам? Нужно ли и можно ли добавить словари? Или попробовать перейти на другой метод поиска (с простого на продвинутый, в инструкции solr описывается такое)? Часто в словах может быть ошибка в одной букве.
2. В документации описывается возможность подсказок при поиске (если не найдено слово, то высвечиваются подсказки известных), но вроде никто не смог это сделать. Ощущение, что именно по фронте убрали такую возможность. Как и вывод части текста из поиска.
3. Как лучше сделать регулярный бэкап? кроном экспорт сообществ/коллекций?
4. Локализация - зачем её делать в бэкэнде? Во фронте вроде все фразы есть, а в документации описано еще изменения в бэке, но как они влияют на результат - не понятно.

Благодарю за любые ответы и подсказки!

Конечно, я всё это говорю из зависти, не иначе, но складывается забавная ситуация всё же... ветки 5 и 6 не по понятиям и с отказом от обязательств заEOLили, седьмой версии наделали пачку релиз кандидатов, мотивируя это тем, что ситуация с 6-й линейкой не должна повториться и версия 7.0 должна быть готовым к промышленному применению dotzero релизом. Как оно вышло на самом деле мы в общем все свидетели :)

По факту сейчас в целом и в частностях в Angular нет паритета по функционалу с "устаревшими" xmlui и jspui, документация оставляет желать лучшего, а видные члены комьюнити нет-нет да и предлагают купить платную поддержку у их конторы :)

Сделали из средненькой коробки, которую можно было худо-бедно селфхостить, еще один ПЛОХОЙ фреймворк, который теперь надо внедрять, а не просто кидать в под, как коробочное решение ранее.

Ну а если по теме, то...

1. SOLR теперь у нас в основном не форкнутый, а ванильный, так что, какой с комьюнити спрос, надо читать тут - [solr.apache.org] и по факту понимать что возможности SOLR обширны, а настройки на стороне dspace скромны. Не думаю что у кого-то есть исчерпывающий практический опыт, рад буду ошибиться.
2. В какой документации? На 5-6 версиях это работало, но лучше бы не работало, в Abgular это могли сломать именно потому, что работает оно не очень.
3. Вариантов масса, в зависимости от того, что Вы хотите получить и что именно (метаданные, данные, весь контент, состояние сервиса, контейнер или виртуальную машину) хотите забекапить. [ideafix.su] оно конечно устарело, это скорее наводящий вопрос,ч ем ответ.
4. Тут же не телепаты. Что именно Вы имеете в виду под локализацией в бэке? Я мутным взором доки (https://wiki.lyrasis.org/display/DSDOC7x) и не очевидно что имелось в виду.

Ну и да... зачем 7 для интранет ресурса?

P.S. Атмира до сих пор пятую версию клиентам продаёт? Или таки обновились?

IdeaFix написал(а):
-------------------------------------------------------

> 3. Вариантов масса, в зависимости от того, что Вы
> хотите получить и что именно (метаданные, данные,
> весь контент, состояние сервиса, контейнер или
> виртуальную машину) хотите забекапить.
> [ideafix.su] оно конечно устарело,
> это скорее наводящий вопрос,ч ем ответ.

Хотелось бы максимально бэкапить - изредка весь сервер, периодически хотя бы БД и папки бэка и фронта. с Ubuntu работал редко, поверхностные знания.
Мысль понял, подумаю даже над устаревшей информацией.

> 4. Тут же не телепаты. Что именно Вы имеете в виду
> под локализацией в бэке? Я мутным взором доки
> (https://wiki.lyrasis.org/display/DSDOC7x) и не
> очевидно что имелось в виду.
[wiki.lyrasis.org]
Тут описано отдельно бэк (вроде для сообщений разных) и фронт (тысяча строк на перевод).

Больше фронт нужно переводить, это освоил. Сомнения появились из-за разделения локализации.

> Ну и да... зачем 7 для интранет ресурса?

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

Рад был бы что-то аналогичное использовать, более проверенное, но среди электронных библиотек ничего не нашлось. Каталогов полно, а библиотек нет.

> P.S. Атмира до сих пор пятую версию клиентам
> продаёт? Или таки обновились?

Да, видел их, но ценник неадекватный (где-то видел его). И импортный saas, могут отключить в любой момент.
Судя по интерфейсу демо, у них 7-я версия в продаже.

По бекапу.

Важно понимать что контент (описания, файлы, пользователи, права, картинки и аннотации коллекций) хранится не только в базе. Есть база и есть асетстор с битстримами. Соответственно, бэкапя только базу (СБУД) Вы получаете нечто, что невозможно будет восстановить, ведь файлов в асетсторе не будет.

Поэтому, если бекапить юниксвейно - то каталог асетстора и дамп базы. Но надо понимать что в какой-то момент объём будет таков, что бекап будет не мновенным, придётся или как-то снапшотить, или останавливать работу на запись в момент бекапа. И только кажется что это фигня.

Опять же, в силу разных причин для dspace важно хранить логи и кеш SOLR. Статистика, всё такое...

Поэтому обычно люди и бэкапят виртуальную машину или контейнер целиком, хотя инструменты для отдельного бекапа контента (макрос AIP позволяет забэкапить наравне с разделами и коллекциями так же и юзерские учетки... но не LDAP конфиг). Ну и по своему опыту могу сказать что на массиве в 100 000 заглавий и более, многие вещи уже не работают. Например, экспорт фонда или экспорт метаданных. И дело не в размере хипа в яве. Просто проблемы роста. В общем, снапшоты виртуалки - наше всё.

По поводу локализации бэкенда всё еще не понятно. Если Вы планируете загружать 100% контента пакетно посредством SAF или REST - это одно, админка (а судя по всему под бэком понимается именно оно) и некоторые служебные вещи возможно действительно не нужны, но если у Вас будет сидеть несколько разных контент-менеджеров на добавление и валидацию добавленного пользователями контента, то сделать им удобный воркфлоу, правильный язык у почтовых уведомлений и др. и пр. как-бы надо.

У DSpace есть один серьезный минус... особенность - никакого дрм. Защита по паролю да, но если пароль есть - выкачать можно всё и сразу. Обычно останавливает как раз это людей, строящих закрытые ресурсы. Из бесплатного только EPRINTS можно рассматривать как коробочное решение, VIVO и FEDORA именно для библиоотеки (склада документов) - слишком круто.

[elib.usma.ru] кстати можете попробовать связаться с коллегами, у них получился очень необычный опыт. Да и у меня с ними тоже... медицинская тематика оказалась очень уж закрытой. Но опыт разработки формата описания, реестра метаданных и структуры там нормальный в общем сложился.

IdeaFix написал(а):
-------------------------------------------------------
> По бекапу.

Понял, проще всю машину бэкапить. А дальше понятно станет по объемам. Может и экспорт обычный делать.

> У DSpace есть один серьезный минус... особенность
> - никакого дрм. Защита по паролю да, но если
> пароль есть - выкачать можно всё и сразу. Обычно
> останавливает как раз это людей, строящих закрытые
> ресурсы.

Есть же разграничение доступа в коллекциях, можно задать доступы к битстримам. У админов полный доступ, у "студентов" только в определенные коллекции, из других коллекций не вытащить данные.
Или есть серьезная уязвимость, что любой зарегистрированный может получить доступ к любым данным?

> Из бесплатного только EPRINTS можно
> рассматривать как коробочное решение, VIVO и
> FEDORA именно для библиоотеки (склада документов)
> - слишком круто.

VIVO и FEDORA - не слышал про них, читаю потихоньку. Вроде аналогичные продукты, но менее распространенные. И русскоязычного сообщества нет.

> [elib.usma.ru] кстати можете попробовать
> связаться с коллегами, у них получился очень
> необычный опыт. Да и у меня с ними тоже...
> медицинская тематика оказалась очень уж закрытой.
> Но опыт разработки формата описания, реестра
> метаданных и структуры там нормальный в общем
> сложился.

Их как раз рассматривал как образец.

elar.urfu.ru, elar.rsvpu.ru, elib.usma.ru, elar.usfeu.ru, elar.uspu.ru и много кто еще сделаны в общем в одной логике... черкните на ideafix@ideafix.name, возможно в телеге или почте будет удобнее пообщаться. На старте репозитория есть не очевидные проблемы, которые лучше сразу обойти, чем потом исправлять.