buddycloud / buddycloud-package Goto Github PK

root@buddycloud:/usr/share/buddycloud-server-java# ls channelserver-0.16.0-SNAPSHOT-jar-with-dependencies.jar configuration.properties configuration.properties.example log4j.properties log4j.properties.example

and in etc

ls -altr /etc/buddycloud-server-java/ total 8 drwxr-xr-x 107 root root 4096 Jul 21 00:52 .. lrwxrwxrwx 1 buddycloud buddycloud 58 Jul 26 21:13 configuration.properties -> /usr/share/buddycloud-server-java/configuration.properties

As per title.

While initializing a buddycloud channel server, I noticed that anything that happens during the script execution is not redirected to the user that executed it.

In my case I was getting an error due to trying to install it in a x86 machine but in order to figure out that was the problem, I had to lookup the script, copy the 'node' command and manually execute it so that I could see its output, which isn't exactly user friendly.

Having anything that happens during the script execution logged would be a good idea.

PS:
I just moved this issue from buddycloud/deprecated-buddycloud-server#114.

Is there a reason to be writing logs to the local FS (and potentially fill the production FS)?

https://github.com/buddycloud/buddycloud-package/blob/master/projects/buddycloud-server-java/docker/log4j.properties#L10

As per title

Most of the packages are failing to build. We need to run them separately and fix the existing issues.

The DB config utility returns this error:

ERROR: encoding UTF8 does not match locale en_GB DETAIL: The chosen LC_CTYPE setting requires encoding LATIN1.

Looks like UTF8 setting in config file is being ignored somewhere.

new install on textras domain

munmap(0x7f705e568000, 1462) = 0
close(3) = 0
stat("/var/run/buddycloud", 0x7fffdc443570) = -1 ENOENT (No such file or directory)
open("/var/run/buddycloud-server-java.pid", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0

@thmr

As in 'wouldn't it be easier to use https://registry.hub.docker.com/u/dockerfile/java/'

There's no (easy) way to know why the current builds are failing. For example: http://downloads.buddycloud.com/packages/debian/nightly/buddycloud-http-api/buddycloud-http-api-0.1+dev20130716.git.7bf8467/

It would be nice to have some output in the directory of where the build is failing so that it's possible to fix.

Right now, if the nightly build script fails to build an specific revision, it does not try to build it again.

As per this discussion: https://groups.google.com/forum/?fromgroups=#!topic/buddycloud-dev/ShM7P5NsJjs

Documentation should also be updated to match the new set up.

There's an issue when installing buddyclcoud-webclient on a machine using nginx - it tries to run a2ensite and fails.

Recent builds seem to be missing their Debian package.

/etc/init.d/buddycloud-server-java start does nothing

As per title.

Apache deployments do work though.

Is this information being exposed publicly on purpose?

https://github.com/buddycloud/buddycloud-package/blob/master/projects/hosting/docker/buddycloud-hosting.cfg#L1-L25

Perhaps output the build log into the target directory so that we can see where it's failing:

eg http://downloads.buddycloud.com/packages/debian/nightly/buddycloud-http-api/buddycloud-http-api-0.1+dev20130626.git.cd04ead/ tells very little about the output of the build.

Using the following docker file to run xmpp-ftw.

After a day or two the process just dies.

https://github.com/buddycloud/buddycloud-package/blob/master/projects/xmpp-ftw/docker/Dockerfile

Currently pulls can fail depending on the current repository status (e.g. if there are modified files there).

Even after unsetting this variable during build time, python's urllib2 seems to be picking up some garbage during runtime, making HTTP requests fail.

Hi Abmar,
it seems that the apache2 process is not coming up everytime the docker gets deployed. One or two restarts of the container helped. May i am the evil one who did a mistake in the Dockerfile, could be very possible in my eyes.
Could you take a look?

�[0m�[91mSaving to: `jdk-7u60-linux-x64.tar.gz'
�[0m�[91m
0K�[0m�[91m �[0m�[91m,�[0m�[91m,�[0m�[91m,�[0m�[91m,�[0m�[91m,�[0m�[91m,�[0m�[91m,�[0m�[91m, ,,,,,,,, ,,,,,,,, ,,,,�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m .�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m .�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m. 2%�[0m�[91m 12.7M 26s�[0m�[91m
3072K .�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m.�[0m�[91m .�[0m�[91m.�[0m�[91m....�[0m�[91m.�[0m�[91m.�[0m�[91m .�[0m�[91m.�[0m�[91m.�[0m�[91m �[0m�[91m 3% 16.1M=0.3s

�[0m�[91m2014-07-13 22:33:18 (7.81 MB/s) - Read error at byte 4441352/142362384 (Connection reset by peer). Giving up.

�[0m�[91mdownload failed
�[0m�[91mOracle JDK 7 is NOT installed.
�[0m�[91mdpkg: error processing oracle-java7-installer (--configure):
subprocess installed post-installation script returned error exit status 1
�[0m�[91mErrors were encountered while processing:
�[0m�[91m oracle-java7-installer

latest is from January:

http://downloads.buddycloud.com/packages/debian/nightly/buddycloud-http-api/buddycloud-http-api-0.1+dev20140128.git.800caac/buddycloud-http-api_0.1+dev20140128.git.800caac-1_amd64.deb

lintian reports several errors for the buddycloud-server Debian package in addtion to warnings.

java -- -Xms1024m -Xmx1024m -XX:-OmitStackTraceInFastThrow -jar /usr/share/buddycloud-server-java/channelserver-0.16.0-SNAPSHOT-jar-with-dependencies.jar

but reference

channelserver-jar-with-dependencies.jar

Media-server deb package must copy configuration.properties.example to configuration.properties in the server's root directory during setup (perhaps changing 'links' would do it)

Although our deb packages support db-config, right now we don't use it in the Dockerfiles. We simply install the packages with a fake connection info and then stage the proper configuration.

Having db-config pre-seeding in place will make DB upgrades a lot smoother.