Вопрос к народу

[Михаил Цветаев]

.....
Ну и обычный вопрос: коллеги, зачем вы под ГВ продолжаете использовать OES? Фантомные боли от нетвари? OES - очень, очень избыточен по ресурсам для ГВ, ему с головой хватит SLES.

Как пример могу предложить свои 5 копеек почему можно ставить GW на OES - это поддержка GW на NSS. Получаете приятный бонус - увеличение раздела NSS без бубна как с ext3/reiser/xfs..... используя или не используя LVM.

[Иван Левшин aka Ivan L.]

Пример - очень так себе. Вы, видимо, путаете том/пул и раздел? Ну и в документации GW, например, написано о том, что, например, Salvage на NSS надо отключать в случае, когда данные GW расположены на NSS: потому, что вместо плюшек можно получить проблемы Никаких очевидных преимуществ у OES перед SLES в случае с GW просто нет.
P.S. Увеличение же пула путем "пришивания" к нему дополнительных разделов - это очень, очень "такое"... Я примерно по тем же причинам никогда никому не рекомендую для хранения данных использовать RAID 0, который Stripe.

[Dimerson]

ХуфФакер (Фамилия такая) с РедЖужу (https://www.redjuju.com/) рекомендует xfs, кстати, и Ext3 всячески подвергает анафеме (см https://www.redjuju.com/groupwise-18-3- ... ice-guide/ ). Впрочем, еще более суровой анафеме он подвергает NSS.

Проанализировав проблему Webaccess на OES2015 (с Tomcat9) таки проще всего сделать так:
распаковываем apache-tomcat-8.0.53.zip в /opt/tomcat8 {в нем bin,lib,webass etc}, зачищаем все примеры из webapps,
создаем симлинки:
в webapps:
gw.war -> /opt/novell/groupwise/webaccess/gw.war
в lib
webservices-api.jar -> /opt/novell/groupwise/webaccess/metro/webservices-api.jar
webservices-extra-api.jar -> /opt/novell/groupwise/webaccess/metro/webservices-extra-api.jar
webservices-extra.jar -> /opt/novell/groupwise/webaccess/metro/webservices-extra.jar
webservices-rt.jar -> /opt/novell/groupwise/webaccess/metro/webservices-rt.jar
webservices-tools.jar -> /opt/novell/groupwise/webaccess/metro/webservices-tools.jar

правим порты:
в gw.conf:
ProxyPass /gw/webacc/poll ajp://localhost:18009/gw/webacc/poll
ProxyPass /gw/webacc ajp://localhost:18009/gw/webacc
в /opt/tomcat8/conf/server.xml: (реально нужны 2 порта на localhost - один для shutdown, второй для AJP коннектора)
<Server port="18005" shutdown="SHUTDOWN">
<Connector port="18009" address="localhost" connectionTimeout="20000" redirectPort="443" protocol="AJP/1.3" maxPostSize="5242880"/>

Все. можно говорить startup.sh Томкату8 и все работает.
Осталось допилить по вкусу правильного TOMCAT_USER (wwwrun:www) и скритпы в /etc/init.d/

Все работает инвариантно к апдейтам.

/etc/systemd/system/tomcat8.service:
[Unit]
Description=Tomcat 8 Servlet Container
Before=multi-user.target graphical.target
After=network-online.target remote-fs.target nss-lookup.target time-sync.target
Wants=network-online.target remote-fs.target

[Service]
User=wwwrun
Group=www
Type=forking
Environment=JAVA_HOME=/usr/lib64/jvm/java
Environment=CATALINA_BASE=/opt/tomcat8
Environment=CATALINA_HOME=/opt/tomcat8
Environment=CATALINA_TMPDIR=/opt/tomcat8/temp
Environment=CATALINA_PID=/opt/tomcat8/logs/tomcat8.pid
ExecStart=/opt/tomcat8/bin/startup.sh
ExecStop=/opt/tomcat8/bin/shutdown.sh
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target


systemctl daemin-reload
systemctl start tomcat8.service

не и наконец
systemctl enable tomcat8.service

That's all folks !

[Иван Левшин aka Ivan L.]

Пусть предает, это нормально, когда человек имеет его собственные заблуждения
Я не вижу никаких особенных причин использовать XFS для ГВ, ext3/ext4 для него - выше башки и с запасом. При этом чинится оно (в случае чего) всяко проще, чем XFS. "Неразваливающуюся" ФС я пока видел только одну и это - ровно NSS. За всю свою практику я видел, наверное, один или два случая, когда оно сдохло в результате, например, выключения по питанию. Нахваливаемый же btrfs, например, умудряется мозг выносить на ровном месте при полном соблюдении всего на свете. XFS у меня так же хандрил несколько раз за последние лет 5... Так что пусть дальше Хуффакер рассказывает о сферических конях в кубическом вакууме, имеет полное на то право
Единственный повод использовать современные ФС в линухах навроде XFS/btrfs: использование SSD. Поддержка TRIM - говорят, полезна.

[Dimerson]

Иван, меня вот тоже терзают смутные сомнения, что восстанавливать XFS как бы нечем особо.

[Иван Левшин aka Ivan L.]

Иван, меня вот тоже терзают смутные сомнения, что восстанавливать XFS как бы нечем особо.

Не, оно работает. Но когда падает - может приключиться боль и печаль: спецтулзы, которые надо доустанавливать (печаль невеликая, просто для ext3/4 все уже сразу установлено), ковыряется ФС долго, исправиться может не с первого раза... Ничего необычного, чем сложнее решение архитектурно (а XFS именно архитектурно сложнее ext3/4, которые, по хорошему, от FAT не сказать, чтобы сильно отличаются) - тем чисто теоретически оно менее надежно При этом я не могу сказать, что вот прям плохая ФС - просто на серверах я ее не использую. На личном ноуте - да, на серверах - нет.

[skoltogyan]

imho:
+ xfs шустрее работает если приложение запускает один поток чтения/записи
и нет много коротких файлов.
+ xfs - стремнее, чем ext4 на жесткие отключения питания ( по результатам получаемой проблемы и по возможностям восстановления файловой системы). повторюсь - это чисто мое ощущение.
+ https://xfs.org/index.php/Shrinking_Support

думаю, что если речь идет о enterprise ( багатые/толстые), то будет настравиаться нечто для создания снапшотов и/или бекапов,
(примерно про это

https://access.redhat.com/documentation ... kuprestore

https://access.redhat.com/documentation ... ch-snapper
)
при таком раскладе - xfs вполне.

[Иван Левшин aka Ivan L.]

Все так. XFS - намного более современная ФС, она и должна быть шустрее и все такое Проблема - ровно в том, что ты описал как "стремнее". Достаточно раз-два на это наступить, чтобы разлюбить XFS совсем.
ГВ не нуждается в таком объеме ввода/вывода со стороны ФС, потому, используя XFS на сервере с ГВ, вы получаете все проблемы XFS без ее преимуществ (которые там, конечно же, есть). NSS избыточен ровно так же. ГВ - это классическое приложение баз данных (оно изначально ровно так и проектировалось), там просто нет настолько активной работы с ФС, чтобы получить возможность наслаждаться прелестями NSS/XFS.

[Dimerson]

Может тогда ZFS подтянем ? Это модное чукалово.

[Иван Левшин aka Ivan L.]

Дак это тот же XFS, вид сбоку Насколько я помню, XFS появился ровно как "наш ответ Чемберлену" для ZFS, там какие-то патентные или правовые дела были... Насколько я помню, конечно - что-то где-то про эту ФС читал в новостях, специально не интересовался.

[Dimerson]

тем не менее с 15-м SLES бывает ZFS (не root естетсвенно) даже описано на офсайте. В отдельном репозитории, для утонченных ценителей.
ZFS-root это для особых экстремалов.

Имхо у них вех ноги растут из одного места с пулами томами раидами и всем таким.
Помните как на OES2 NSS ставился через EVMS2 ?

[Иван Левшин aka Ivan L.]

Стараюсь не вспоминать

[Dimerson]

Сижу. Никого не трогаю. OES2018 обновляю (это OES2018SP2 с отключенным OES ... на нем SMT и Sep Sesam).
Делаю значится zypper up -t patch ..... reboot .... и внезапно бакапный софт отпал. наглухо. пишет колл саппорт DB is empty.
База с бакапами заданиями итд привязанными к автолоадеру.

Покурил.

К базенке ручками тук-тук а она пишет тут файлы созданы в 10 версии а я уже 14.

Хорошо быть знакомым с Debian.
дело было в update-alternatives --config postgresql
он гад 14 версию выставил.
вернул на 10 и полегчало.

Начальство заставляет патчить все. Мать их.