Hi Markus,
Your post #120. Does it mean that I don’t have to issue the command…
yum -y install https://mrmarkuz.goip.de/mirror/devtest/nethserver-zammad-1.0.0-5.ns7.noarch.rpm
… after instaling Elasticsearch and before installing Zammad?
Michel-André
yap, the CSRF issue has been sorted and now able to login. whoosh…
No, it was an answer for @oneitonitram because he needs this fix for the csrf problem.
The installation configures Zammad too so it may help to (re)install if signal-event nethserver-zammad-update does not work.
@mrmarkuz jus ton a separate note, where and how do you document your stuff…
i mean, it can get crazy
elastic search was not broken, since i had installe abit ealier.
this will be cool, especially for future new users.
I use dokuwiki and textfiles.
Hi Markus,
I looked at my old documentation and the refusal of connection was solved by:
# db configuration setprop sshd AutoBlock disabled
But I think it is not used by NethServer.
Michel-André
To Nitram:
I am doing a documentation on how to install Zammad. The only thing left is the reboot after an update.
Please test and report…
Update:
yum -y --enablerepo=mrmarkuz update https://mrmarkuz.dynu.net/mirror/devtest/nethserver-zammad-1.0.0-6.ns7.noarch.rpm elasticsearch
Fresh install (replace <VHOST> with the Zammad vhost):
yum install https://mrmarkuz.dynu.net/mirror/devtest/nethserver-zammad-1.0.0-6.ns7.noarch.rpm`
config setprop zammad VirtualHost <VHOST>
yum -y --enablerepo=mrmarkuz install zammad
signal-event nethserver-zammad-update
Hi Markus,
For the update of Zammad, you’re the hero of the day !
It works perfectly even after a reboot.
After the update of Zammad, I did:
# signal-event nethserver-zammad-update
#
Then if I update Elasticsearch:
# yum update -y elasticsearch
...
Mis à jour :
elasticsearch.x86_64 0:7.6.2-1
#
…
# signal-event nethserver-zammad-update
#
…
# systemctl status elasticsearch.service
● elasticsearch.service - Elasticsearch
Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; enabled; vendor preset: disabled)
Active: failed (Result: timeout) since sam. 2020-04-11 01:43:14 EDT; 4min 36s ago
Docs: http://www.elastic.co
Main PID: 6310 (code=exited, status=143)
avril 11 01:41:43 tchana.micronator-dev.org systemd[1]: Starting Elasticsearch...
avril 11 01:41:47 tchana.micronator-dev.org elasticsearch[6310]: OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweep...ase.
avril 11 01:43:13 tchana.micronator-dev.org systemd[1]: elasticsearch.service start operation timed out. Terminating.
avril 11 01:43:14 tchana.micronator-dev.org systemd[1]: Failed to start Elasticsearch.
avril 11 01:43:14 tchana.micronator-dev.org systemd[1]: Unit elasticsearch.service entered failed state.
avril 11 01:43:14 tchana.micronator-dev.org systemd[1]: elasticsearch.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
#
…
# systemctl stop elasticsearch.service
#
…
# systemctl start elasticsearch.service
Job for elasticsearch.service failed because a timeout was exceeded. See "systemctl status elasticsearch.service" and "journalctl -xe" for details.
#
…
# journalctl -xe
avril 11 01:49:15 tchana.micronator-dev.org kernel: IPv4: martian source 10.10.10.76 from 10.10.10.81, on dev enp0s8
avril 11 01:49:15 tchana.micronator-dev.org kernel: ll header: 00000000: ff ff ff ff ff ff d0 27 88 8f 9c bf 08 06 .......'......
avril 11 01:49:16 tchana.micronator-dev.org kernel: IPv4: martian source 10.10.10.76 from 10.10.10.81, on dev enp0s8
avril 11 01:49:16 tchana.micronator-dev.org kernel: ll header: 00000000: ff ff ff ff ff ff d0 27 88 8f 9c bf 08 06 .......'......
avril 11 01:49:17 tchana.micronator-dev.org kernel: IPv4: martian source 10.10.10.76 from 10.10.10.81, on dev enp0s8
avril 11 01:49:17 tchana.micronator-dev.org kernel: ll header: 00000000: ff ff ff ff ff ff d0 27 88 8f 9c bf 08 06 .......'......
avril 11 01:49:18 tchana.micronator-dev.org kernel: IPv4: martian source 10.10.10.76 from 10.10.10.81, on dev enp0s8
avril 11 01:49:18 tchana.micronator-dev.org kernel: ll header: 00000000: ff ff ff ff ff ff d0 27 88 8f 9c bf 08 06 .......'......
avril 11 01:49:18 tchana.micronator-dev.org auth[6907]: pam_sss(dovecot:auth): authentication success; logname= uid=0 euid=0 tty=dovecot ruser=admin rhos
avril 11 01:49:19 tchana.micronator-dev.org kernel: IPv4: martian source 10.10.10.76 from 10.10.10.81, on dev enp0s8
avril 11 01:49:19 tchana.micronator-dev.org kernel: ll header: 00000000: ff ff ff ff ff ff d0 27 88 8f 9c bf 08 06 .......'......
avril 11 01:49:20 tchana.micronator-dev.org dovecot[1814]: imap-login: Login: user=<admin>, method=PLAIN, rip=10.10.10.75, lip=10.10.10.75, mpid=7476, TL
avril 11 01:49:20 tchana.micronator-dev.org kernel: IPv4: martian source 10.10.10.76 from 10.10.10.81, on dev enp0s8
avril 11 01:49:20 tchana.micronator-dev.org kernel: ll header: 00000000: ff ff ff ff ff ff d0 27 88 8f 9c bf 08 06 .......'......
avril 11 01:49:21 tchana.micronator-dev.org kernel: IPv4: martian source 10.10.10.76 from 10.10.10.81, on dev enp0s8
avril 11 01:49:21 tchana.micronator-dev.org kernel: ll header: 00000000: ff ff ff ff ff ff d0 27 88 8f 9c bf 08 06 .......'......
avril 11 01:49:22 tchana.micronator-dev.org kernel: IPv4: martian source 10.10.10.76 from 10.10.10.81, on dev enp0s8
avril 11 01:49:22 tchana.micronator-dev.org kernel: ll header: 00000000: ff ff ff ff ff ff d0 27 88 8f 9c bf 08 06 .......'......
avril 11 01:49:23 tchana.micronator-dev.org dovecot[1814]: imap(admin@micronator-dev.org): Connection closed (EXPUNGE finished 0.041 secs ago) in=76 out=
avril 11 01:49:24 tchana.micronator-dev.org kernel: IPv4: martian source 192.168.1.1 from 192.168.1.163, on dev enp0s3
avril 11 01:49:24 tchana.micronator-dev.org kernel: ll header: 00000000: ff ff ff ff ff ff a0 b3 cc cc 43 6e 08 06 ..........Cn..
avril 11 01:49:58 tchana.micronator-dev.org auth[6907]: pam_sss(dovecot:auth): authentication success; logname= uid=0 euid=0 tty=dovecot ruser=admin rhos
avril 11 01:49:58 tchana.micronator-dev.org dovecot[1814]: imap-login: Login: user=<admin>, method=PLAIN, rip=10.10.10.75, lip=10.10.10.75, mpid=7528, TL
avril 11 01:50:01 tchana.micronator-dev.org dovecot[1814]: imap(admin@micronator-dev.org): Connection closed (EXPUNGE finished 0.069 secs ago) in=76 out=
avril 11 01:50:02 tchana.micronator-dev.org systemd[1]: Started Session 12 of user root.
-- Subject: L'unité (unit) session-12.scope a terminé son démarrage
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- L'unité (unit) session-12.scope a terminé son démarrage, avec le résultat done.
avril 11 01:50:02 tchana.micronator-dev.org CROND[7541]: (root) CMD (/usr/libexec/nethserver/awstatsCronJobs)
avril 11 01:50:21 tchana.micronator-dev.org systemd[1]: elasticsearch.service start operation timed out. Terminating.
avril 11 01:50:22 tchana.micronator-dev.org systemd[1]: Failed to start Elasticsearch.
-- Subject: L'unité (unit) elasticsearch.service a échoué
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- L'unité (unit) elasticsearch.service a échoué, avec le résultat failed.
avril 11 01:50:22 tchana.micronator-dev.org systemd[1]: Unit elasticsearch.service entered failed state.
avril 11 01:50:22 tchana.micronator-dev.org systemd[1]: elasticsearch.service failed.
avril 11 01:50:22 tchana.micronator-dev.org polkitd[791]: Unregistered Authentication Agent for unix-process:7341:234327 (system bus name :1.53, object p
avril 11 01:50:34 tchana.micronator-dev.org auth[6907]: pam_sss(dovecot:auth): authentication success; logname= uid=0 euid=0 tty=dovecot ruser=admin rhos
avril 11 01:50:34 tchana.micronator-dev.org dovecot[1814]: imap-login: Login: user=<admin>, method=PLAIN, rip=10.10.10.75, lip=10.10.10.75, mpid=7600, TL
avril 11 01:50:35 tchana.micronator-dev.org dovecot[1814]: imap(admin@micronator-dev.org): Connection closed (EXPUNGE finished 0.001 secs ago) in=76 out=
#
I am pretty sure it’s a question of timing.
It is not sshd as for a test I modified AutoBloc to no avail.
I tried to add a delay in /usr/lib/systemd/system/elasticsearch.service just after [Service].
[Service]
ExecStartPre=/usr/bin/sleep 100
That didn’t worked also.
For a last resort, I chmod +x /etc/rc.d/rc.local and add for the last line:
(/usr/bin/sleep 100 ; /usr/bin/systemctl stop elasticsearch.service ; /usr/bin/systemctl start elasticsearch.service )
I am sure that this is not the proper way to do it, but with that, Elasticsearch is always working after a reboot.
Michel-André
Update works well 
Had no time to test it until now…
Hi Károly,
Which update: Zammad, Elasticsearch, or both ?
Even after a reboot?
Michel-André
Well, it was only nethserver-zammad first, now I ran the update to both zamamd and elasticsearch, and now it is broken…
elasticsearch 5.6.16-1 was the version that worked previously
Edit:
Exception java.lang.IllegalStateException: The index [[zammad_production/fy8dpUQOQV6hb97aFpFq_g]] was created with version [5.6.16] but the minimum compatible version is [6.0.0-beta1]. It should be re-indexed in Elasticsearch 6.x before upgrading to 7.6.2.
So I guess we need to remove the index file manually, and reinstall elasticsearch.
Edit 2:
Solved this way (no mercy):
rm -rf /var/lib/elasticsearch/*
yum reinstall elasticsearch
systemctl start elasticsearch
signal-event nethserver-zammad-update
It survived 2 reboots so far…
BUT this looks different from your issue!
Thanks for testing!
I put elasticsearch 7 to my repo so now Zammad installation should get the newer ES version and there should be no index update problem anymore.
I think about adding your lines to a script or at least to the wiki…
Hi Markus,
Do I have to rebuiltd the index with:
# zammad run rake searchindex:rebuild
or will it be rebuild automatically ?
Thank you in advance,
Michel-André
With the test package it is rebuilt automatically.
I can reproduce the problem on a high load server.
Adding TimeoutStartSec=300 to the [service] section of the systemd file /etc/systemd/system/multi-user.target.wants/elasticsearch.service helped. Use systemctl daemon-reload to apply immediately.
Elasticsearch takes about 3 minutes to start on that server and the default of 90 seconds is too less in this case.
I have same issue on that server with netdata but it does a restart (maybe a good method for ES too):
# restart netdata if it crashes
Restart=on-failure
RestartSec=30
Hi Markus,
You’re still the greatest ! Your solution works perfectly.
I read all the links you suggested and in one of them it pointed to a link (How To Use Systemctl to Manage Systemd Services and Units | DigitalOcean), which says to modify with systemctl edit elasticsearch.service.
I tried that.
It didn’t work the first time because I only added the parameter.
I added: [Service] and under it: TimeoutStartSec=300 and this time, it worked.
I tried that way because someone wrote that if you vi the file directly, the modifications will be erased by an update. (centos - How to change systemd service timeout value? - Unix & Linux Stack Exchange)
Instead of editing the package’s service file in
/usr/lib/systemd/system/which will get overridden on package upgrade…
It talked about editing in /usr/lib... which is not what you wrote which says to edit in /etc/systemd/system/...
To verify, I added TimeoutStartSec=300 in /etc/systemd/system/..., then upated - the added parameter didn’t get erased in /etc/systemd/system/....
Do you think that it is better to use systemctl edit elasticsearch.service or it is not necessary?
Michel-André
No, I think editing the files in /etc/… should work. They shouldn’t be replaced on updates.
And are these files object of backup?
Good point. No, they are not yet. I’d include them to config backup. Another way would be using a template.