Created attachment 157594 [details] shar file for www/sogo New port for www/sogo. SOGo is a highly scalable groupware solution. Visit http://www.sogo.nu/ for more information about it. This is my first set of ports, although I have packaged for Linux distros for a while. So I'm not currently a port maintainer. It's not trivial, more of a slow port I'd say. But one I need quite badly myself, since I run it in production for 3 companies and my own personal mail domain. It is in the WantedPorts, and it's been wanted for a long time now. I've tested that it builds on 8.4, 9.3 and 10.1. I also have been running it on my own server (10.1-RELEASE) for a few months now without any problems. I use FreeBSD exclusively on servers and have a vested interest in the OS and these ports for the forseeable future.
Forgot to mention: this port requires a dependency devel/sope which I have submitted a PR and shar file for separately.
Hi Euan, thanks for your submission. Please include QA results as per my comment in bug 200751 so that this issue can be progressed as quickly as possible
FYI, CVE-2015-5395 -- No CSRF token - requests can be forged http://www.openwall.com/lists/oss-security/2015/07/07/10 http://www.sogo.nu/bugs/view.php?id=3246 This should be addressed before a known vulnerable version gets committed.
Just tried a fresh poudriere build and discovered a few minor issues: 1) Makefile post-stage (cp ${FILESDIR}/sieve.creds.sample ${STAGEDIR}${ETCDIR}/) sieve.cred.sample does not exist in files/ 2) files/expire-autoreply.creds.sample It appears this file is not used as part of the port. Maybe you made a typo in the Makefile and pkg-plist? 3) Missing UIDs / GIDs I had to add the following: echo "sogod:*:994:994::0:0:SOGo user:/nonexistent:/usr/sbin/nologin" >> UIDs echo "sogod:*:994:" >> GIDs I took this from https://github.com/ethoms/freebsd-ports
(In reply to Matthew Bowman from comment #4) > 1) Makefile post-stage > > (cp ${FILESDIR}/sieve.creds.sample ${STAGEDIR}${ETCDIR}/) > > sieve.cred.sample does not exist in files/ Thanks for pointing this out, I've fixed it now. The sieve.cred.sample was renamed to expire-autoreply.creds.sample. > > 2) files/expire-autoreply.creds.sample > > It appears this file is not used as part of the port. Maybe you made a typo in > the Makefile and pkg-plist? > Same as above, it was renamed but not changed in Makefile. Read the pkg-message to see what it's used for. > 3) Missing UIDs / GIDs > > I had to add the following: > > echo "sogod:*:994:994::0:0:SOGo user:/nonexistent:/usr/sbin/nologin" >> UIDs > echo "sogod:*:994:" >> GIDs That's normal, you have to add it manually until it get's accepted in official porfs tree. It is mentioned in the README.md instructions.
(In reply to Jason Unovitch from comment #3) Thanks for the heads up. I guess I will have update the port to a newer version of sogo upstream. I struggling to get time to do the QA testing. Hopefully I can do it soon.
Created attachment 161261 [details] Latest shar submission for new port. Updated to version 2.3.2. The port builds fine, and it works. However, the stage-qa test fails since there is a false positive on the stage directory strings test of one lib file. This is the error message: ====> Running Q/A tests (stage-qa) Error: 'GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/2/sogo/libSOGo.so.2.3.2' is referring to /wrkdirs/usr/ports/www/sogo/work/stage *** Error code 1 Please see following freebsd-forums thread discussing this issue: https://forums.freebsd.org/threads/q-a-tests-fail-even-though-port-builds-installs-and-works.50186/ And also, the sogo mailing list, whereby the developerss have not answered the question about the strange lib strings issue: http://comments.gmane.org/gmane.comp.groupware.sogo.user/22362 Note that the port installs fine and even after a "make clean" that lib file runs fine. SOGo has been running perfectly on my servers for over 6 months now. That lib file is critical to the daemon service of sogo.
Testing@work
issue while linking (missing -lSBJson): /usr/bin/ld: warning: libSBJson.so.2, needed by ../SoObjects/SOGo/SOGo.framework/sogo/libSOGo.so, not found (try using -rpath or -rpath-link) ../SoObjects/SOGo/SOGo.framework/sogo/libSOGo.so: undefined reference to `__objc_class_name_SBJsonParser'
The cause for the compile-time path in libSOGo.so is, well, from it's GNUstep upbringing. gnustep-make - defines in /usr/local/GNUstep/System/Library/Makefiles/Instance/framework.make - the creation of a so-called DUMMY_FRAMEWORK_FILE - which will contain the value of FRAMEWORK_INSTALL_DIR - which comes from SoObjects/SOGo/GNUmakefile - defining itself part of a framework by setting FRAMEWORK_NAME = SOGo - which causes SOGo_INSTALL_DIR to be used in Instance/framework.make to be expanded to the wrong FRAMEWORK_INSTALL_DIR in derived_src/NSFramework_SOGo.m - which is then compiled into NSFramework_SOGo.o and added to libSOGO.so, where it probably is never used - This generation of the .o even happens twice o once for wobundle Appointments o and once for framework SOGo. So the question is: Where can we hook into this mess to fix NSFramework_SOGo.m before it is compiled ?
(In reply to Kurt Jaeger from comment #9) Oh, I never noticed that. But the installed service runs fine, and I think I use just about all features of the groupware server. Do I need to address this? Perhaps adding another dependancy for libSBJson?
(In reply to Kurt Jaeger from comment #10) Wow, well done for finding the root cause so fast. THis is getting at least a little out of my league. I'll try to look at the code for that file. I know some C/C++, but I don't know Objective C at all.
A commit references this bug: Author: pi Date: Wed Sep 23 05:30:17 UTC 2015 New revision: 397608 URL: https://svnweb.freebsd.org/changeset/ports/397608 Log: New port: www/sogo SOGo is a fully supported and trusted groupware server with a focus on scalability and open standards. It provides a rich AJAX-based Web interface and supports multiple native clients through the use of standard protocols such as CalDAV, CardDAV and GroupDAV. WWW: http://sogo.nu/ PR: 200750 Submitted by: Euan Thoms <euan@potensol.com> Changes: head/GIDs head/UIDs head/www/Makefile head/www/sogo/ head/www/sogo/Makefile head/www/sogo/distinfo head/www/sogo/files/ head/www/sogo/files/cron-ealarms-notify.sample head/www/sogo/files/cron-expire-autoreply.sample head/www/sogo/files/ealarms-notify.creds.sample head/www/sogo/files/expire-autoreply.creds.sample head/www/sogo/files/patch-Main_GNUmakefile.preamble head/www/sogo/files/patch-SoObjects_SOGo_GNUmakefile head/www/sogo/files/patch-SoObjects_SOGo_NSData+Crypto.m head/www/sogo/files/patch-SoObjects_SOGo_instance-framework.make head/www/sogo/files/patch-SoObjects_SOGo_master-framework.make head/www/sogo/files/patch-Tests_Unit_GNUmakefile head/www/sogo/files/patch-Tools_GNUmakefile.preamble head/www/sogo/files/sogod.in head/www/sogo/pkg-descr head/www/sogo/pkg-message head/www/sogo/pkg-plist
Committed as 397608.
Just to finalise things. I've just updated my production system using the committed port. Everything seems fine so far. So it passes my initial (basic) runtime test.
!!! NOTE !!! You will need to run database upgrade scripts if upgrading from 2.2.17 or below. I had to modify the script a little bit. Below are some useful notes. I use postgresql, so use the mysql update script if needed. Add to PATH variable: # PATH=$PATH:/usr/local/GNUstep/System/Tools; export PATH source the GNUstep environment: # . /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh modify script: # cd /usr/ports/www/sogo # make extract # cd work/SOGo-2.3.2/Scripts # vi sql-update-2.2.17_to_2.3.0.sh 1.) LINE1: change /bin/bash to /usr/local/bin/bash (or you could try out /bin/sh) 2.) LINE14: change /etc/sogo/sogo.conf to /usr/local/etc/sogo/sogo.conf 3.) save and exit stop service: # service sogod stop run script: # ./sql-update-2.2.17_to_2.3.0.sh 1.) enter database connection details 2.) voila! start service: # service sogod start That's all folks! P.S. in futuer versions of the port I will need to patch and install these update scripts. Let's hope there's not too many going forward.
A commit references this bug: Author: pi Date: Tue Sep 29 05:19:42 UTC 2015 New revision: 398158 URL: https://svnweb.freebsd.org/changeset/ports/398158 Log: www/sogo: fix UIDs/GIDs, as numerical value 845 collides with hast PR: 200750 Submitted by: Euan Thoms <euan@potensol.com> (maintainer) Changes: head/GIDs head/UIDs