SOGo 3.2.4 Packages needs testing

Development Testing
,
1

In the nethforge-testing repository are (self build) packages for SOGo 3.2.0 4.
It are strait-forward un-patched builds against epel-7, Sope is a build dependency of Sogo.

Still struggling with the release tag of sope as described here

They need testing!

To update:
yum upgrade --enablerepo=nethforge-testing sogo* sope*

One issue i have encountered once is sending mail from firefox did not work.
Emptying the cache of firefox fixed it.

Thanx in advance!

EDIT: bumped to 3.2.4
Note: The netserver-sogo package it self is still WIP, and not included in this testing-update.

4 Likes
2

hey mark,
have installed the 3.2 and everything seems to be good. No probs with access, also active sync works well, will give you a shout if i got something what does not work. have a great day !

1 Like
3

It did not sovled this yet, it works for you because you fixed manually yourself. :ok_hand:
Working on it :slight_smile:

1 Like
4

well i fix it with the information from you, so again thanks for that and for you in the case “testing 3.2” also the active sync works with your workaround on 3.2 :slight_smile:

5

It works like a charm! :+1:
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
6

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 :slight_smile:

2 Likes
7

Confirmed on my fresh installation. Thanks @alefattorini for the workaround.

1 Like
8

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
9

Hi @mark_nl first of all a big big thanks for your work!! :clap: :clap: :clap:
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. :sweat:

This is a problem of displaying:

Pasted image1336Ă—330 14 KB

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
10

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
11

Did notice this as well, the fist time can take a long time. Especially the calender settings,
which browser do you use?

1 Like
12

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
13

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
14

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.

15

Good Morning Mark,

this morning I figured out how to access the settings, do you find the difference? :wink:

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:

1 Like
16

Hi Slavo,

with firefox and IE also no display arifacts. But IE11 is very slow.

Pasted image1002Ă—364 20.3 KB

17

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
18

Hi mark,

now I’m a little ashamed. To clear the browser chache resolved it. Could have this idea on my own. :blush:

19

Oh no, its useful feed back! :+1:

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)

20

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! :+1:

3 Likes