It works like a charm! 
Just a hint, I needed to run in order to see SOGo login page
signal-event nethserver-sogo-update
Looks like sogod didn’t restart after the update
2 Likes
strange, this should do the job:
%post
# update timestamp on imgs,css,js to let apache know the files changed
find %{_libdir}/GNUstep/SOGo/WebServerResources -exec touch {} \;
# make shells scripts in documentation directory executable
find %{_docdir}/ -name '*.sh' -exec chmod a+x {} \;
%if 0%{?_with_systemd}
systemctl daemon-reload
systemctl enable sogod
systemctl start sogod > /dev/null 2>&1
ill look in to it 
2 Likes
Hi @mark_nl
I see that /etc/sogo/sogo.conf, which contains passwords, is 644. Is that something related to your packages?
Thanks
2 Likes
Hi @mark_nl first of all a big big thanks for your work!! 
I have greatest respect that you faced the challenge to bring Sogo 3.x to NS7!!
I’ve just installed Sogo 3.2. It’s my Open-LDAP-testinstallation on V7, not AD-DC. (Virtulabox VM)
Can access with administrator and with user, but I’ve some issues:
I can only access the general settings, but not the calendar, e-mail or adressbook settings. 
This is a problem of displaying:
The box is a bit to small, although i can choose the numbers so it’s only cosmetic.
I did a reboot, but didn’t help.
@hucky do the settings work at your installation?
1 Like
Hi Salvo,
Thanx for the feedback!
This is not related to the SOGo 3.2.0 packages , but is related to the new nethserver-sogo package:
Did you install this as well?
1 Like
Did notice this as well, the fist time can take a long time. Especially the calender settings,
which browser do you use?
1 Like
It seems to be memcached or httpd, sogod restarts the after update. memcached should clear its cache, not sure if it does. Httpd should see the webresources are new, we give them a new timestamp while updating.
Still looking in to this.
1 Like
This works for me, instead! And no display artifacts, too, on Firefox 49.0.2. Perhaps you’ve cached an older stylesheet or Javascript? They updated AngularJS between 3.0 and 3.2 IIRC.
2 Likes
I think so: I did a fresh installation of Nethserver 7rc1, did upgrades in Software center, installed several packages including Sogo Groupware. Then, I’ve issued yum upgrade --enablerepo=nethforge-testing sogo* sope* as per your instructions to upgrade to 3.2.0.
Good Morning Mark,
this morning I figured out how to access the settings, do you find the difference? 
I’ve to put the mouse in the upper third, then a darkgrey bar appears on that i’ve to klick.
I used chrome. I tried now with firefox an with that it works normaly. Thanks for the hint. 
1 Like
Could you try to figure out how to empty the brower-cache of chrome and see if it works after emptying it?
Thx for testing
2 Likes
Hi mark,
now I’m a little ashamed. To clear the browser chache resolved it. Could have this idea on my own. 
Oh no, its useful feed back! 
I’m going to do some tests on a single core VM this afternoon/evening, i have a hunch SOGo tries to spawn multiple workers and this could cause troubles on a single core. (just thinking out loud here, i’ll report back)
In this case you did not update the nethserver-sogo package, you don’t need to.
ahah: now get your question, yes it’s 644 by design and i am going to solve this in the new nethserver-sogo package.
We need group read permissions for the the sogo group for easy use of sogo-tool. sogo.conf should be owned by root:sogo, others should not have read permissions.
Thanx for pointing this out!
3 Likes
took a while,
Done in nethforge testing, version 1.6.1-1.14.g6835f7b.
3 Likes
Great work!
1 Like
Updated 3.0.2 to 3.2.4 on a ns7-rc3 vm without problems. Authentication on local AD still works.
Will play a bit with it and report if any issue appears. Thanks for your work again Mark.
Hope you’re doiing well with your new job.
3 Likes
Still in testing? Looks stable to me, I’d like to move it on the update channel, what’s missing?