Koozali.org: home of the SME Server
Obsolete Releases => SME 9.x Contribs => Topic started by: guest22 on April 15, 2016, 11:01:44 AM
-
Hi,
there is a new howto in progress for Rocket.Chat: https://wiki.contribs.org/Rocket_Chat (https://wiki.contribs.org/Rocket_Chat)
It's not really finished yet (Hence the WIP notice), but the current raw notes should get you up and running. It worked for me.
Please provide your feedback here, so we can fine tune the howto.
TIA.
https://snowulf.com/2015/09/25/why-slack-when-you-can-rocket-chat/
-
Very interesting, and timely. With the news (https://www.techdirt.com/articles/20160414/10482434186/canadian-law-enforcement-can-intercept-decrypt-blackberry-messages.shtml) that law enforcement has a backdoor into BlackBerry, I'm looking for something secure and cross-platform. This may do it.
-
Starting to work through the instructions on a test VM. I note that you set up repositories for scl and centos-sclo-rhl, but your yum install has --enablerepo=centos-rh-scl,epel. Looks like a mismatch, and the result is that a few of the packages (didn't note which ones) aren't found.
I changed the name of centos-sclo-rhl to centos-rh-scl, and the yum install worked fine.
The remainder of the instructions went without error until the end, where you're supposed to start Rocket.Chat:
[root@sme-test2 ~]# cd /opt/Rocket.Chat/programs/server/
[root@sme-test2 server]# ls
app boot.js config.json npm package.json program.json
assets boot-utils.js mini-files.js npm-shrinkwrap.json packages shell-server.js
[root@sme-test2 server]# node main.js &
[1] 2962
[root@sme-test2 server]#
module.js:340
throw err;
^
Error: Cannot find module '/opt/Rocket.Chat/programs/server/main.js'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:935:3
[1]+ Exit 8 node main.js
[root@sme-test2 server]#
-
Thanks Dan, start instructions corrected. Will check the other feedback over the weekend.
ps. enable repo command adjusted too.
-
Still not starting:
[root@sme-test2 Rocket.Chat]# node main.js &
[1] 23653
[root@sme-test2 Rocket.Chat]#
/opt/Rocket.Chat/programs/server/node_modules/fibers/future.js:245
throw(ex);
^
Error: MONGO_URL must be set in environment
at Object.<anonymous> (packages/mongo/remote_collection_driver.js:36:1)
at Object.defaultRemoteCollectionDriver (packages/underscore/underscore.js:750:1)
at new Mongo.Collection (packages/mongo/collection.js:102:1)
at AccountsServer.AccountsCommon (accounts_common.js:23:18)
at new AccountsServer (accounts_server.js:16:5)
at Package (globals_server.js:5:12)
at /opt/Rocket.Chat/programs/server/packages/accounts-base.js:1814:4
at /opt/Rocket.Chat/programs/server/packages/accounts-base.js:1825:3
at /opt/Rocket.Chat/programs/server/boot.js:242:10
at Array.forEach (native)
[1]+ Exit 8 node main.js
[root@sme-test2 Rocket.Chat]#
I thought it might be a result of the boot scripts not being executable, so I changed that (chmod +x /etc/profile.d/scls*) and tried again, but had the same result. scls-rh-mongodb26 is there, and it does define MONGO_URL.
-
Thanks again Dan. Please allow me to check over the weekend. CET +1 here.
-
Ok, I fixed some things and typo's. Should all be working now.
@DanB35, please do the following on your test VM install:
cd /opt/Rocket.Chat/programs/server
npm install
adjust /etc/profile.d/scls-rh-mongodb26 and add .sh to the end of the filename (scls-rh-mongodb26.sh)
adjust the content of scls-rh-mongodb26.sh according to the wiki
reboot
start Rocket.Chat: node /opt/Rocket.Chat/main.js &
-
I'd reverted the test VM to a previous snapshot (clean 9.1 install with current updates), so I couldn't test if the changes in your last post, standing alone, solved my issue. However, going back through the wiki's current instructions got me further than before.
I note that the reboot you mention in your last post is necessary, though I don't see it in the wiki. Whether it's just to start mongod (which could be easily handled by 'service mongod start') or something else, I'm not sure, but 'node main.js' failed in exactly the same way as before if I didn't reboot. After the reboot, it runs without apparent error.
After that, if I browse to http://myserver:3000, I get the login screen. If I go to https://myserver:3000, it can't connect. It seems to be working at this point--I'll have to play around with it and see how far I get.
-
I note that the reboot you mention in your last post is necessary, though I don't see it in the wiki. Whether it's just to start mongod (which could be easily handled by 'service mongod start') or something else, I'm not sure, but 'node main.js' failed in exactly the same way as before if I didn't reboot. After the reboot, it runs without apparent error.
The reboot is required to auto load all the /etc/profile.d entries for the Software Collections applications.
After that, if I browse to http://myserver:3000, I get the login screen. If I go to https://myserver:3000, it can't connect. It seems to be working at this point--I'll have to play around with it and see how far I get.
A secure connection with Rocket.Chat (httpS) is in the making. However, using the webapps-common contrib and create a sub-domain with proxypass (as per the wiki) will enforce a secure connection via Apache.
-
It's running fine now on it's own subdomain via a secure connection and LDAP authentication.
Amazing piece of software, all the WebRTC stuff is working great too! Should be a contrib to add value to SME Server ;-)
-
A secure connection with Rocket.Chat (httpS) is in the making. However, using the webapps-common contrib and create a sub-domain with proxypass (as per the wiki) will enforce a secure connection via Apache.
Fine, but the wiki also says:
Browse to https://yourserver:3000 and create the first admin user.
...and that won't work. Or, at least, it didn't work for me.
-
Fine, but the wiki also says:...and that won't work. Or, at least, it didn't work for me.
Corrected. It should be http
-
Looking at the ProxyPass configuration makes me wonder--would it be possible to run Rocket.Chat on an internal, private server, and point ProxyPassTarget to that server? The wiki instructions result in installing a bunch of dependencies, and I'm not sure that I'm comfortable putting all that on my production server. But if I can spin up a clean SME9 VM, install Rocket.Chat on it, and point https://chat.mydomain to the internal box, I don't need nearly as much installed on the prod box, what is there can be easily removed if desired, and any attack coming by way of Rocket.Chat is going to affect only that internal VM.
-
Yep, possible. Hence the sub domain, which can be any server.
ps. LDAP authentication (if used) needs to be adjusted then too.
-
OK, I've got everything (that's documented on the wiki page so far) working. Rocket.Chat is installed on an internal server, and the ProxyPass configuration is forwarding chat.mydomain to it without issues. Somewhat surprisingly, the ProxyPass setup didn't interfere with getting a Let's Encrypt cert for that hostname either. The mobile app also seems to be working on my Android phone.
Edit: Though it seems account activation emails aren't being sent, and this message is appearing in the logs: "(Mail not sent; to enable sending, set the MAIL_URL environment variable.)". I've configured the mail server in Administration/SMTP, and the test email button reports success, but no messages are actually sent.
Something that might be helpful until the init script is working properly--install tmux (yum --enablerepo=epel install tmux). Then create a new session (tmux new) and start Rocket.Chat inside that session (node main.js). You can then detach from that session and leave it running (Ctrl-B d), log out of the server, etc. When you log back in, run tmux a to re-attach to that session. This will leave the server running while you log out.
-
Something that might be helpful until the init script is working properly--install tmux (yum --enablerepo=epel install tmux). Then create a new session (tmux new) and start Rocket.Chat inside that session (node main.js). You can then detach from that session and leave it running (Ctrl-B d), log out of the server, etc. When you log back in, run tmux a to re-attach to that session. This will leave the server running while you log out.
Thanks Dan, screen ( https://www.gnu.org/software/screen/manual/screen.html ) would do the same and is already installed with SME Server by default.
The init script works great, but I need the correct sed command to add SME Server to the list of known distributions for the forever tool. Will take a few minutes, and the knowledge that it can be done easily had my focus on LDAP, which is not correctly working...
-
Edit: Though it seems account activation emails aren't being sent, and this message is appearing in the logs: "(Mail not sent; to enable sending, set the MAIL_URL environment variable.)". I've configured the mail server in Administration/SMTP, and the test email button reports success, but no messages are actually sent.
Added to the TODO list on the wiki page.
-
Thanks Dan, screen ( https://www.gnu.org/software/screen/manual/screen.html ) would do the same and is already installed with SME Server by default.
I expect so, I'm just a little more familiar with tmux. But if the init script is taken care of anyway, this point becomes moot.
my focus on LDAP, which is not correctly working...
I'm not sure what's going on there. The logs seem to say it's connecting just fine, but it doesn't pull the user list over.
-
Added to the TODO list on the wiki page.
This issue looks like the same thing: https://github.com/RocketChat/Rocket.Chat/issues/2471
Restarting the Rocket.Chat server got rid of the "set MAIL_URL" message, but now it's showing this instead:
Exception while invoking method 'registerUser' DeliveryError: Message delivery failed: 552 Mail with no Date header not accepted here
at Object.Future.wait (/opt/Rocket.Chat/programs/server/node_modules/fibers/future.js:398:15)
at smtpSend (packages/email/email.js:86:1)
at Object.Email.send (packages/email/email.js:185:1)
at AccountsServer.Accounts.sendVerificationEmail (password_server.js:781:9)
at [object Object].Meteor.methods.registerUser (server/methods/registerUser.coffee:20:13)
at [object Object].methodsMap.(anonymous function) (server/lib/debug.js:23:26)
at maybeAuditArgumentChecks (livedata_server.js:1698:12)
at livedata_server.js:708:19
at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1)
at livedata_server.js:706:40
- - - - -
at SMTPConnectionPool._onConnectionReady (/opt/Rocket.Chat/programs/server/npm/email/node_modules/simplesmtp/lib/pool.js:287:21)
at SMTPClient.emit (events.js:98:17)
at SMTPClient._actionStream (/opt/Rocket.Chat/programs/server/npm/email/node_modules/simplesmtp/lib/client.js:946:14)
at SMTPClient._onData (/opt/Rocket.Chat/programs/server/npm/email/node_modules/simplesmtp/lib/client.js:329:29)
at CleartextStream.emit (events.js:95:17)
at CleartextStream.<anonymous> (_stream_readable.js:765:14)
at CleartextStream.emit (events.js:92:17)
at emitReadable_ (_stream_readable.js:427:10)
at _stream_readable.js:420:7
at process._tickDomainCallback (node.js:492:13)
-
Looking at the subdomain instructions, it seems to me that the DocumentRoot setting is unnecessary--you're directing Apache to proxy the connection to a completely different server, so Apache won't be serving files out of /opt/Rocket.Chat (or anywhere else). I left that property out on my installation (didn't make any sense anyway, since my rocket.chat install was on a different host), and it still seems to work without issue.
-
Looking at the subdomain instructions, it seems to me that the DocumentRoot setting is unnecessary--you're directing Apache to proxy the connection to a completely different server, so Apache won't be serving files out of /opt/Rocket.Chat (or anywhere else). I left that property out on my installation (didn't make any sense anyway, since my rocket.chat install was on a different host), and it still seems to work without issue.
Would that be the same for the 'Content Primary' directive?
-
Would that be the same for the 'Content Primary' directive?
I'd think so, but I haven't tried it that way yet. Any time you set up a domain in the sever-manager, though, the system wants you to assign an ibay to it. I'm not sure how it would deal with not having one.
Edit: At first glance, though, it seems to work with that property deleted as well.
-
@DanB35, would you be kind enough to test the auto start as per wiki here https://wiki.contribs.org/Rocket_Chat#Auto_start_Rocket.Chat_at_boot (https://wiki.contribs.org/Rocket_Chat#Auto_start_Rocket.Chat_at_boot)
Maybe the scripts in /etc/profile.d need to executable but I am not sure for there is a mix of legacy scripts in there with different chmod statuses.
TIA
-
I followed those instructions, and they seem to have worked. After running "service rocketchat start" and waiting a minute or so, I was able to access the installation. After rebooting the VM, Rocketchat started automatically and I was able to access it.
I did note an oddity on restarting, though. mongod took nearly 10 minutes to start. The proxmox console showed a sustained disk read of about 5M (though it isn't labeled with units--whether that's Mbits/sec, Mbytes/min, or Mwords/fortnight isn't clear) during that time, at the end of which there was a write spike of ~38M. I have no idea if this has anything to do with the packages installed--it could be my VM provisioning, my VM host's hardware, or any of a number of other things.
-
I followed those instructions, and they seem to have worked. After running "service rocketchat start" and waiting a minute or so, I was able to access the installation. After rebooting the VM, Rocketchat started automatically and I was able to access it.
Thanks, marked verified ;-)
I did note an oddity on restarting, though. mongod took nearly 10 minutes to start. The proxmox console showed a sustained disk read of about 5M (though it isn't labeled with units--whether that's Mbits/sec, Mbytes/min, or Mwords/fortnight isn't clear) during that time, at the end of which there was a write spike of ~38M. I have no idea if this has anything to do with the packages installed--it could be my VM provisioning, my VM host's hardware, or any of a number of other things.
Let's put it on the TODO list. I had a sence it had something to do with MongoDB. Although I see a difference instead of using service, using /etc/rc.d/rocketchat restart etc directly. Need to find out this one.
-
Edit: Though it seems account activation emails aren't being sent, and this message is appearing in the logs: "(Mail not sent; to enable sending, set the MAIL_URL environment variable.)". I've configured the mail server in Administration/SMTP, and the test email button reports success, but no messages are actually sent.
Please see https://github.com/RocketChat/Rocket.Chat/issues/2471 (https://github.com/RocketChat/Rocket.Chat/issues/2471)
I've adapted the init script creation command to include it. Please stop Rocket.Chat, remove /etc/rc.d/init.d/rocketchat and follow this part again https://wiki.contribs.org/Rocket_Chat#Generate_the_Rocket.Chat_init_script (https://wiki.contribs.org/Rocket_Chat#Generate_the_Rocket.Chat_init_script)
-
April 30th, corrected some typo's in the how-to.
-
I want to try and run this myself. When I get some time over the next few weeks I may try and build an rpm but will need a hand if anyone is willing.
Is there a srpm for rocket out there anywhere ? Also wondering about how to automatically pull in node.js on install ?
Home Tuesday so will gave a look after that.
-
Is there a srpm for rocket out there anywhere ?
This may help https://copr-be.cloud.fedoraproject.org/results/mosquito/rocketchat/fedora-22-x86_64/00170401-rocketchat/ (https://copr-be.cloud.fedoraproject.org/results/mosquito/rocketchat/fedora-22-x86_64/00170401-rocketchat/)
Please note that the current release schedule of Rocket.Chat is weekly....
-
Restarting the Rocket.Chat server got rid of the "set MAIL_URL" message, but now it's showing this instead:
Exception while invoking method 'registerUser' DeliveryError: Message delivery failed: 552 Mail with no Date header not accepted here
So the app needs to be fixed so that it sends RFC compliant mail messages - Date header is mandatory.
-
Edit: At first glance, though, it seems to work with that property deleted as well.
Looking at the source code of smesever-webapps-common it seems that the priority evaluation order of db properties is:
1. ProxyPass
2. Rewrite
3. Redirect
So basically, next to the default command line arguments, only setting the ProxyPassTarget property would do the job in case of a ProxyPass situation.
ps. Need to add this to the wiki.
-
Somewhat surprisingly, the ProxyPass setup didn't interfere with getting a Let's Encrypt cert for that hostname either.
That may have to do with http://gitweb.firewall-services.com/?p=smeserver-webapps-common;a=patch;h=c200387012776f811e0b06408332add8535712eb (http://gitweb.firewall-services.com/?p=smeserver-webapps-common;a=patch;h=c200387012776f811e0b06408332add8535712eb)
-
Having a fiddle with this today.
As far as building a RPM the tricky bit is handling nodejs
For the moment I am looking at a manual install of node first, followed my the rpm which will take care of most of the rest and add some configurability.
Couple of things.
First is I cannot modify the installer.js as per the wiki. The forever service seems to install happily but......
And then this happens:
sed -i -e 's/(Oracle Linux)/(Oracle Linux)|(SME Server)/' \
/opt/rh/nodejs010/root/usr/lib/node_modules/forever-service/templates/sysvinit/installer.js
sed: can't read /opt/rh/nodejs010/root/usr/lib/node_modules/forever-service/templates/sysvinit/installer.js: No such file or directory
As a result I cannot see the startup script that it generates - I was wondering if it would be simpler to use our own (the forever service may not then be required) which could also then be modified as a template.
Any hints or tips ?
-
Something must have gone wrong in the previous step installing forever and forever-service, for those commands install the target file 'installer.js'
-
ps. from within a script you may have to use the following:
scl enable nodejs010 bash
npm install -g forever
npm install -g forever-service
exit 0
-
ps. from within a script you may have to use the following:
scl enable nodejs010 bash
npm install -g forever
npm install -g forever-service
exit 0
Thanks. That seemed to work on the CLI - for some reason it failed before. Will re test.
-
Appears to me that you did not reboot where the wiki said you should :wink:
-
Thanks. That seemed to work on the CLI - for some reason it failed before. Will re test.
From within an RPM, I guess a 'reboot' is not the preferred way :) So we need to make all boot scripts executable and execute them opposed to a reboot.
See Dan35 suggestion.
-
Ok I am making a little progress.
I am not exactly sure how to get round the node js things so am tackling it a little differently by installing the node js bit first and then add the rpm to enable you to reconfigure stuff.
Basic code is here but I really wouldn't try it just yet ;-)
https://github.com/reetp/smeserver-rocketchat
As soon as I have something workable I'll post a link for those who like to break things :hammer:
-
Koozali SME Server has been added to the PAAS deployment list by the Rocket.Chat team.
@Rocket.Chat team, Thanks!
https://rocket.chat/docs/master/installation/paas-deployments/koozali/ (https://rocket.chat/docs/master/installation/paas-deployments/koozali/)
-
Koozali SME Server has been added to the PAAS deployment list by the Rocket.Chat team.
@Rocket.Chat team, Thanks!
https://rocket.chat/docs/master/installation/paas-deployments/koozali/ (https://rocket.chat/docs/master/installation/paas-deployments/koozali/)
Yes I saw that - nice one !
OK, I have a modifiable init script now. Need to sort some variables though.
-
ps. from within a script you may have to use the following:
scl enable nodejs010 bash
npm install -g forever
npm install -g forever-service
exit 0
Using npm should be avoided if possible. It means that you have software installed which isn't controlled and managed by rpm.
I know that npm is the 'standard' way that nodejs packages are installed, but it is problematic. See:
http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
-
Using npm should be avoided if possible. It means that you have software installed which isn't controlled and managed by rpm.
I know that npm is the 'standard' way that nodejs packages are installed, but it is problematic. See:
http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ (http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)
Isn't this why we use Software Collections and all dependencies etc go into /opt/rh or other specific Software Collections directories?
-
I've gotten rid of the forever-service module. and templated the initscript it generated
The forever module seems to be some sort of init wrappery type of thing. If I can figure how to dispense with it at some point I will, but I have spent my time on templating the other stuff so far.
Still working on it and will come back to this later.
-
Isn't this why we use Software Collections and all dependencies etc go into /opt/rh or other specific Software Collections directories?
Nop, SCL are "just" rpms repo, and are fine (doesn't matter if they install in /usr or in /opt as long as they are managed by yum). Npm is NodeJS "package manager", just like cpan is to perl. When possible, it's best to install only RPM and not rely on this kind of package management. But with NodeJS, it's hard, most of the time, you have to use npm.
-
Got that, still npm under SCL still installs ONLY in the SCL environment. So as far as stock SME Server concerns, it is not effected AFAIK. Hence the enable command.
-
It's not the fact that you use SCL. Npm install dependencies in the working directory of your project, not system wide. So indeed, you won't polute the system. But updates won't be managed automatically with yum, you'll have to use npm to do that
-
It's not the fact that you use SCL. Npm install dependencies in the working directory of your project, not system wide. So indeed, you won't polute the system. But updates won't be managed automatically with yum, you'll have to use npm to do that
Agree. One of the downsides of the upside of using SCL.
-
It'd be the same without SCL (with the stock nodejs/npm). Here, SCL only gets a new enough node environment
-
Not completely correct. NPM packages are installed under the SCL environment (thus /opt/rh) structure. Stock SME Server will still not be effected.
-
Quick update.
My contrib vaguely works.
However, after thinking I had written crap code it transpires that there are issues with email.js not sending mails in a RFC compliant format, or at least one that SME is happy with.
Two issues....
First is the'From' header is not set by email.js on the default install.... this can be modified once you have logged in. So your initial setup mail won't go through even though the account is setup.
Second is that email.js does not set a Date header. Double whammy... !
If I can figure some JS I'll try a patch and see if I can get it merged.
Onwards and upwards.... albeit slowly !
-
OK - just posted at the meteor forums
https://forums.meteor.com/t/email-flagged-as-spam/5576/8
I don't get JS so any help gratefully received :-)
-
Unfortunately, even if required, this missing Date headers rejects more and more valid email. Newer version of qpsmtpd, and its headers checker plugin has disabled this requirement by default because too many legitimate email forget this one
-
Well, I'm kind of getting there a bit but...
mc = new MailComposer();
# Set up the date
var dateObj = new Date();
# Convert to UTC - all good so far
dateObj = dateObj.toUTCString();
# Convert the date to a string (we could probably add it direct but..... don't know how)
var newDate = String (dateObj);
# Concatenate test and date
newDate = "date: " + newDate;
# Add our header - trouble is knowing what is already in there - I don't know how to add to existing elements ??
# This seems to work on a JS test but fails in email.js (or at least it fails to send with same error 552) - which I could debug it :-(
object = {header: [newDate]};
// setup message data
mc.setMessageOption({
from: options.from,
to: options.to,
cc: options.cc,
bcc: options.bcc,
replyTo: options.replyTo,
subject: options.subject,
text: options.text,
html: options.html
});
_.each(options.headers, function (value, name) {
mc.addHeader(name, value);
});
# blah....
Some notes from the JS file
* @param {Object} options
* @param {String} options.from "From:" address (required)
* @param {String|String[]} options.to,cc,bcc,replyTo
* "To:", "Cc:", "Bcc:", and "Reply-To:" addresses
* @param {String} [options.subject] "Subject:" line
* @param {String} [options.text|html] Mail body (in plain text and/or HTML)
* @param {Object} [options.headers] Dictionary of custom headers
Oh for some perl :-)
Time for bed Zebedee.... boinnnnnng
-
Bit more thinking on this.... my guess is the object variable is in this type of format:
var options = {
from: 'some person',
to: 'someone else',
cc: 'some cc',
text: 'some text',
headers: {
date: 'date now',
another: 'other data'
}
};
You then get
options.from
options.to
etc etc
So the question is how do you add another element to the headers without losing what MAY be there ?
-
Another issue I just fell over. Trying to enable https. Added webapps. Added the subdomain as per the wiki.
That connects fine through the proxy. However, I cannot generate a letsencrypt certificate for the host/domain
[root@test letsencrypt.sh]# letsencrypt.sh -c
# INFO: Using main config file /etc/letsencrypt.sh/config.sh
Processing chat.reetspetit.info with alternative names: reetspetit.info mail.reetspetit.info test.reetspetit.info www.reetspetit.info
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting challenge for chat.reetspetit.info...
+ Requesting challenge for reetspetit.info...
+ Requesting challenge for mail.reetspetit.info...
+ Requesting challenge for test.reetspetit.info...
+ Requesting challenge for www.reetspetit.info...
+ Responding to challenge for chat.reetspetit.info...
ERROR: Challenge is invalid! (returned: invalid) (result: {"type":"http-01","status":"invalid","error":{"type":"urn:acme:error:unauthorized","detail":"Invalid response from http://chat.reetspetit.info/.well-known/acme-challenge/13x4OOCTg8YN8758RU4DK3Atbj2BLta_oslRQCidfgI [212.83.164.73]: 403"},"uri":"https://acme-v01.api.letsencrypt.org/acme/challenge/z8VL-s91k-aiiAKmHX3jUPB3DRwM0NEVuDjDx3R34lk/72772938","token":"13x4OOCTg8YN8758RU4DK3Atbj2BLta_oslRQCidfgI","keyAuthorization":"13x4OOCTg8YN8758RU4DK3Atbj2BLta_oslRQCidfgI._IYt1sNfNVNxGFTcIFNdJOP9E8mKxnAdY8DKER_1h1M","validationRecord":[{"url":"http://chat.reetspetit.info/.well-known/acme-challenge/13x4OOCTg8YN8758RU4DK3Atbj2BLta_oslRQCidfgI","hostname":"chat.reetspetit.info","port":"80","addressesResolved":["212.83.164.73"],"addressUsed":"212.83.164.73"}]})
I guess the proxy is routing the request to something internal in RocketChat rather than to the standard Primary ibay / .well-known/acme-challenge
Any ideas on how to get round this ? Does the reverse proxy need an entire subdomain ? Will a host not do the job ?
-
That may have to do with http://gitweb.firewall-services.com/?p=smeserver-webapps-common;a=patch;h=c200387012776f811e0b06408332add8535712eb (http://gitweb.firewall-services.com/?p=smeserver-webapps-common;a=patch;h=c200387012776f811e0b06408332add8535712eb)
I think that is an older patch from looking at the git account and comparing to mine.
Seems with my letsencrypt contrib and webapps I cannot get a cert for chat.reetspetit.net - seems fubar'd
+ Responding to challenge for chat.reetspetit.info...
ERROR: Challenge is invalid! (returned: invalid) (result: {"type":"http-01","status":"invalid","error":{"type":"urn:acme:error:unauthorized","detail":"Invalid response from http://chat.reetspetit.info/.well-known/acme-challenge/3e4wXyIVcpNDXeAZPirqHj624rpOe_xtqAQLDL5tLD8 [212.83.164.73]: 403"},"uri":"https://acme-v01.api.letsencrypt.org/acme/challenge/dTtVq4BkM-wjr0r8nTX68Q2YE0VpuGAHS_IPbuoSBZQ/72935804","token":"3e4wXyIVcpNDXeAZPirqHj624rpOe_xtqAQLDL5tLD8","keyAuthorization":"3e4wXyIVcpNDXeAZPirqHj624rpOe_xtqAQLDL5tLD8._IYt1sNfNVNxGFTcIFNdJOP9E8mKxnAdY8DKER_1h1M","validationRecord":[{"url":"http://chat.reetspetit.info/.well-known/acme-challenge/3e4wXyIVcpNDXeAZPirqHj624rpOe_xtqAQLDL5tLD8","hostname":"chat.reetspetit.info","port":"80","addressesResolved":["212.83.164.73"],"addressUsed":"212.83.164.73"}]})
The section in httpd.conf looks like this
<VirtualHost 0.0.0.0:443>
ServerName chat.reetspetit.info
ServerAlias
SSLEngine on
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
# alias for Apache icons
Alias /icons/ /var/www/icons/
ProxyPass /.well-known/acme-challenge/ !
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
I guess the '!' at the end of the line means ignore requests, but it seems it doesn't.
I also think that you should probably set the Content to Primary as that where .well-known/acme-challenge is ?
chat.reetspetit.info=domain
Content=Primary
-
@ReetP
I'm not sure what's going on with your setup (or mine, for that matter), but I was able to get an LE cert, using your RPM, after setting up the proxy.
-
Yes I have realised I may have a separate issue.
/me tosses away another VM !
-
FYI https://metacpan.org/pod/Net::RocketChat
-
@ReetP
I'm not sure what's going on with your setup (or mine, for that matter), but I was able to get an LE cert, using your RPM, after setting up the proxy.
Dan, I just setup a fresh Rocket, then converted to https.
In Firefox it seems fine with a green padlock and seems happy with a cert from reetspetit.info , but Chrome (and the mobile apps which are Chrome based) refuse to connect with an untrusted cert warning. They seem to want chat.reetspetit.info
I then decided to get a new cert for the chat.reetspetit.info domain and that failed :
ERROR: Challenge is invalid! (returned: invalid) (result: {"type":"http-01","status":"invalid","error":{"type":"urn:acme:error:unauthorized","detail":"Invalid response from http://chat.reetspetit.info/.well-known/acme-challenge/wlq0-2LB6zE4OFjDTsKIv1YyzEucxcv0QhjMr9tD5Cc [212.83.164.73]: 403"},"uri":"https://acme-v01.api.letsencrypt.org/acme/challenge/wspQmnDgEj67loPwElX78KFtSFfUBjhwD5nvBZlMc68/75050731","token":"wlq0-2LB6zE4OFjDTsKIv1YyzEucxcv0QhjMr9tD5Cc","keyAuthorization":"wlq0-2LB6zE4OFjDTsKIv1YyzEucxcv0QhjMr9tD5Cc._IYt1sNfNVNxGFTcIFNdJOP9E8mKxnAdY8DKER_1h1M","validationRecord":[{"url":"http://chat.reetspetit.info/.well-known/acme-challenge/wlq0-2LB6zE4OFjDTsKIv1YyzEucxcv0QhjMr9tD5Cc","hostname":"chat.reetspetit.info","port":"80","addressesResolved":["212.83.164.73"],"addressUsed":"212.83.164.73"}]})
httpd error_log
[error] [client 66.133.109.36] access to /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge/wlq0-2LB6zE4OFjDTsKIv1YyzEucxcv0QhjMr9tD5Cc failed, reason: SSL connection required
Clearly there is still something not quite right. I'm not sure how I can get chat.reetspetit.info to access the .well-know directory.
Any bright ideas ?
-
[error] [client 66.133.109.36] access to /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge/wlq0-2LB6zE4OFjDTsKIv1YyzEucxcv0QhjMr9tD5Cc failed, reason: SSL connection required
Your Primary ibay is set to require SSL on, without a transparent redirection. So Letsencrypt servers tries to verify your challenge, but can't get it. You should allow plain http access to the Primary ibay (or at least send a 301 redirect to the HTTPS equivalent, but there's no real point in having ACME challenges sent over HTTPS, as your certificate won't be validated by Letsencrypt servers). Why would this only affect chat.reetspetit.info is a mystery.
-
Your Primary ibay is set to require SSL on, without a transparent redirection. So Letsencrypt servers tries to verify your challenge, but can't get it. You should allow plain http access to the Primary ibay (or at least send a 301 redirect to the HTTPS equivalent, but there's no real point in having ACME challenges sent over HTTPS, as your certificate won't be validated by Letsencrypt servers). Why would this only affect chat.reetspetit.info is a mystery.
Thanks Daniel. I'll do that as it matters not on this particular box, though it may be an issue if someone wants everything https
Just disabled SSL
db accounts setprop Primary SSL disabled
signal-event ibay-modify
Then ran letsencrypt and it worked OK
Just wondering whether we could use say an .htaccess file in there to divert any normal request to https but let requests to .well-known go through as http ?
-
Just wondering whether we could use say an .htaccess file in there to divert any normal request to https but let requests to .well-known go through as http ?
In smeserver-webapps-common when a domain is set to be SSL only, I add this:
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule ^/(.*|$) https://%{HTTP_HOST}/$1 [L,R]
This way, all requests using plain HTTP are redirected to their HTTPS equivalent, except for ACME challenges. To have the same working on the Primary domain would require a small template addition
-
In smeserver-webapps-common when a domain is set to be SSL only, I add this:
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule ^/(.*|$) https://%{HTTP_HOST}/$1 [L,R]
This way, all requests using plain HTTP are redirected to their HTTPS equivalent, except for ACME challenges. To have the same working on the Primary domain would require a small template addition
Yes for this I am using your contrib. Would be a nice addition :-)
Oddly on my other boxes with SSL set to enabled letsencrypt does not seem to have a problem, so there is something weird going on ! I did wonder if it was that the domain had no default Content set but I tried to add Primary and it still tries to jump to https and rocketchat and then just hangs there.
http://test.reetspetit.info/.well-known/acme-challenge/ - you can see the directory
http://chat.reetspetit.info/.well-known/acme-challenge/ - tries to connect to Rocket and hangs
:confused.com:
-
Another issue...
Just trying to figure out how to get over this error
WebSocket connection to 'wss://chat.reetspetit.info/sockjs/929/yy5rc90p/websocket' failed: Error during WebSocket handshake: Unexpected response code: 400
I then added the wss2 line and that seemed to clear the error - I could add a template fragment for this in the RocketChat contrib
ProxyPass /.well-known/acme-challenge/ !
ProxyPass /wss2/ wss://localhost:3000/
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
Issue reported all over the place - here is a solution using nginx
https://forums.meteor.com/t/how-do-you-fix-websocket-error/2827/7
Video/Audio still not working properly - sometimes it does, and sometimes not, sometimes a call will go one way but not another. All a bit hit and miss !
-
Apache on SME9 has no support for WebSocket proxypass, so:
ProxyPass /wss2/ wss://
Won't work. I guess the JS client lib has some fallback mechanism when WS isn't available (using HTTP and tricks like polling). At least, Socket.IO has this. Don't know what Rocket is using.
-
W
Apache on SME9 has no support for WebSocket proxypass, so:
ProxyPass /wss2/ wss://
Won't work. I guess the JS client lib has some fallback mechanism when WS isn't available (using HTTP and tricks like polling). At least, Socket.IO has this. Don't know what Rocket is using.
Odd as the only way I could get rid of the error was as above..... I read that apache 2.4 on CentOS 6 seems to handle this ?
e.g. https://www.softwareab.net/wordpress/websockets-centos-6-apache-2-4/
-
Apache 2.4 from SCL should support it, but stock apache on SME9 is 2.2
-
Apache 2.4 from SCL should support it, but stock apache on SME9 is 2.2
Not sure if I have an SCL upgrade on this v9 box but I get
[root@test conf]# rpm -qa |grep apache
e-smith-apache-2.4.0-15.el6.sme.noarch
root@test conf]# rpm -qi e-smith-apache-2.4.0-15.el6.sme.noarch
Name : e-smith-apache Relocations: (not relocatable)
Version : 2.4.0 Vendor: Contribs.org <http://contribs.org>
Release : 15.el6.sme Build Date: Sat 23 Jan 2016 06:23:56 PM CET
Install Date: Tue 15 Mar 2016 10:51:54 AM CET Build Host: builder.koozali.org
Group : Networking/Daemons Source RPM: e-smith-apache-2.4.0-15.el6.sme.src.rpm
Size : 49944 License: GPL
Signature : DSA/SHA1, Sat 23 Jan 2016 06:45:04 PM CET, Key ID 3d7205081e9c9308
Packager : Contribs.org <http://contribs.org>
Summary : e-smith server and gateway - apache module
Description :
e-smith server and gateway software - apache module.
So I think it is 2.4 ?
-
Nop. This is the version for the smeserver integration package. To get the engine version, use rpm -q httpd
-
Nop. This is the version for the smeserver integration package. To get the engine version, use rpm -q httpd
[root@test ~]# rpm -q httpd
httpd-2.2.15-47.el6.centos.4.x86_64
Odd as the errors stopped after I added it. Hmmmm... maybe this is part of the issue with the video/audio then
-
Actually tried it again and sometimes you see them on login but not thereafter. Hmmmmm
-
Apache on SME9 has no support for WebSocket proxypass, so:
ProxyPass /wss2/ wss://
Won't work. I guess the JS client lib has some fallback mechanism when WS isn't available (using HTTP and tricks like polling). At least, Socket.IO has this. Don't know what Rocket is using.
Just for ref when looking at this I saw
https://github.com/socketio/socket.io/issues/1696
Comment from Toub that he got it running for socket.io on 2.22 so a possible solution there but way beyong my skillset
-
I have a compiled mod_proxy_wstunnel for el6 in my repo, but I haven't tested it at all (yet)
-
I have a compiled mod_proxy_wstunnel for el6 in my repo, but I haven't tested it at all (yet)
Yes, I was trying it :-)
-
OK, I have found a possible fix for mail:
[root@test opt]# diff -ruN ./Rocket.Chat/programs/server/npm/email/node_modules/mailcomposer/lib/mailcomposer.js ./Rocket.Chat/programs/server/npm/email/node_modules/mailcomposer/lib/mailcomposer.orig
--- ./Rocket.Chat/programs/server/npm/email/node_modules/mailcomposer/lib/mailcomposer.js 2016-05-07 14:07:22.426311320 +0200
+++ ./Rocket.Chat/programs/server/npm/email/node_modules/mailcomposer/lib/mailcomposer.orig 2016-05-07 14:12:58.010375819 +0200
@@ -99,11 +99,6 @@
this._gencounter = 0;
this.addHeader("MIME-Version", "1.0");
-// Set up the date
- var dateObj = new Date();
-// Convert to UTC
- dateObj = dateObj.toUTCString();
// Now add the header element
- this.addHeader("Date", dateObj);
};
/* PUBLIC API */
This forces all mails to have the date added (I think !)
HOWEVER !
This does not fix the email issue on install as there is no 'From' address until such time as the DB is populated
It probably needs something along the lines of 'if From == '' then From == 'admin@locahost' or somesuch or alternatively add something to the DB on install of the contrib. I'll look at that later.
There is also a coding bug in the Subject Line for mails which adds <br> to the subject line. I'll try and find a fix for that as well, but it is just cosmetic and can be overridden by a custom template in Rocket.
Let me know if this make any difference please.
-
I have a compiled mod_proxy_wstunnel for el6 in my repo, but I haven't tested it at all (yet)
Using your RPM and the below http settings, there are no more 'ws' errors. So it seems that your RPM is working just fine, also according to other log files.
https://wiki.contribs.org/Talk:Rocket_Chat (https://wiki.contribs.org/Talk:Rocket_Chat)
-
As a FYI I now have two contrib RPMs
smeserver-rocketchat - this adds the rocketchat init service and manages some settings
rocketchat - this is the main 'app' bundle
I have made notes here :
https://wiki.contribs.org/Rocket_Chat:Contrib
I am still trying to work out some more logic for different configurations
As far as I can see there would be:
Local access only
Remote access via http
Remote access via https
Remote access via http/proxy
Remote access via https/proxy
I have been testing with HSF and we can run it from Remote using https and a reverse proxy using Daniels mod_proxy contrib to get Voice and Video calls
Each of these options could be to the main host, or to a subdomain on the host, or even elsewhere. Gets a bit tricky at that point due to the httpd.conf configurations/permutations !
If anyone wants to have a play then please let me know and I can explain some config options
B. Rgds
John
-
Tried your contrib until the db command:
[root@sme9chat ~]# db setprop rocketchat status enabled
usage:
/sbin/e-smith/db dbfile keys
/sbin/e-smith/db dbfile print [key]
/sbin/e-smith/db dbfile show [key]
/sbin/e-smith/db dbfile get key
/sbin/e-smith/db dbfile set key type [prop1 val1] [prop2 val2] ...
/sbin/e-smith/db dbfile setdefault key type [prop1 val1] [prop2 val2] ...
/sbin/e-smith/db dbfile delete key
/sbin/e-smith/db dbfile printtype [key]
/sbin/e-smith/db dbfile gettype key
/sbin/e-smith/db dbfile settype key type
/sbin/e-smith/db dbfile printprop key [prop1] [prop2] [prop3] ...
/sbin/e-smith/db dbfile getprop key prop
/sbin/e-smith/db dbfile setprop key prop1 val1 [prop2 val2] [prop3 val3] ...
/sbin/e-smith/db dbfile delprop key prop1 [prop2] [prop3] ...
-
corrected on the wiki page.
-
I used:
db configuration setprop rocketchat status enabled
instead of:
db setprop rocketchat status enabled
but on the end I was not able to start the service:
[root@sme9chat ~]# service rocketchat restart
Shutting down rocketchat: /etc/rc.d/init.d/rocketchat: Zeile 104: /opt/rh/nodejs010/root/usr/lib/node_modules/forever/bin/forever: Datei oder Verzeichnis nicht gefunden
Not running
/etc/rc.d/init.d/rocketchat: Zeile 64: /opt/rh/nodejs010/root/usr/lib/node_modules/forever/bin/forever: Datei oder Verzeichnis nicht gefunden
Starting rocketchat
/etc/rc.d/init.d/rocketchat: Zeile 82: /opt/rh/nodejs010/root/usr/lib/node_modules/forever/bin/forever: Datei oder Verzeichnis nicht gefunden
"Datei oder Verzeichnis nicht gefunden" means "File or Folder not found" ...
-
I used:
db configuration setprop rocketchat status enabled
instead of:
db setprop rocketchat status enabled
Or you could have used:
config setprop rocketchat status enabled
-
Sorry but am on holiday at the minute.
FYI from v0.40 onwards a higher version of nodejs than is provided by SCL is required.
I have got v0.42 running but have not documented it as yet, nor looked at building a RPM, as it requires a different setup. I'll look further in a week or so.
B. Rgds
John
-
OK, John. Please let me know when you are ready...
Best
fpausp
-
Just setup a new test box and I am going to try and write up how to install for 0.40 +
I have 0.44 (current) running on another machine but it is a manual hack.
I'll write back once I have some notes.
B. Rgds
John
-
OK John, sounds good...
-
OK, a couple of RPMs to test.
Please DON'T try this on a production box. Test boxes that you do no value ONLY. You have been warned.
Read these notes first :
https://github.com/reetp/smeserver-rocketchat/blob/master/Notes-0.44.txt
You can get the RPMs here - I've only just built them and not even installed them myself yet.....:
First one alows you to manage settings:
wget https://www.reetspetit.com/Test/smeserver-rocketchat-0.1-6.noarch.rpm
This one includes a patched version of rocket.chat for mailcomposer Missing header
wget https://www.reetspetit.com/Test/rocketchat-0.0.44.0-1.noarch.rpm
You can yum localinstall them at the relevant points in the notes.
You can anualy download and install rocket directly like this:
wget https://rocket.chat/releases/0.44.0/download; tar zxvf rocket.chat.tgz; mv bundle /opt/Rocket.Chat
Check the permissions on the files in /opt
I also have it running with HTTPS and reverse proxy. If anyone wants a test login on my test box to play and chat then let me know.
I will have a go at installing from the ground up myself tomorrow but am going out for dinner now !
Let me know if there are any issues.
B. Rgds
John
-
OK, updated today to v 0.45 so I built a new RPM
wget https://www.reetspetit.com/Test/rocketchat-0.0.45.0-1.noarch.rpm
I managed to upgrade my main test box without any issues - it barfs a lot whilst it is upgrading whilst it messes with node/npm, but the upshot is it came back up without any intervention :-)
Beware -I have seen a report that audio is scuppered with 0.45 and you can't downgrade. https://github.com/RocketChat/Rocket.Chat/issues/4808
I am just rebuilding a local V9 VM so I can test on a clean install. Will advise accordingly.
Let me know if there are any issues.
B. Rgds
JC
-
[root@sme9test ~]# yum localinstall rocketchat-0.0.45.0-1.noarch.rpm
Geladene Plugins: fastestmirror, smeserver
Einrichten der lokalen Paketverarbeitung
Untersuche rocketchat-0.0.45.0-1.noarch.rpm: rocketchat-0.0.45.0-1.noarch
Markiere rocketchat-0.0.45.0-1.noarch.rpm zum Installieren
Determining fastest mirrors
* base: mirror.nextlayer.at
* smeaddons: mirror.pialasse.com
* smeextras: mirror.pialasse.com
* smeos: mirror.pialasse.com
* smeupdates: mirror.pialasse.com
* updates: mirror.nextlayer.at
base | 3.7 kB 00:00
base/primary_db | 4.7 MB 00:15
smeaddons | 2.9 kB 00:00
smeaddons/primary_db | 1.2 kB 00:00
smeextras | 2.9 kB 00:00
smeextras/primary_db | 109 kB 00:00
smeos | 3.1 kB 00:00
smeos/primary_db | 1.1 MB 00:04
smeupdates | 2.9 kB 00:00
smeupdates/primary_db | 500 kB 00:03
updates | 3.4 kB 00:00
updates/primary_db | 3.1 MB 00:09
Löse Abhängigkeiten auf
--> Führe Transaktionsprüfung aus
---> Package rocketchat.noarch 0:0.0.45.0-1 will be installiert
--> Abhängigkeitsauflösung beendet
Abhängigkeiten aufgelöst
=================================================================================================================================================================
Paket Arch Version Repository Grösse
=================================================================================================================================================================
Installieren:
rocketchat noarch 0.0.45.0-1 /rocketchat-0.0.45.0-1.noarch 352 M
Vorgangsübersicht
=================================================================================================================================================================
Install 1 Package(s)
Gesamtgrösse: 352 M
Installed size: 352 M
Ist dies in Ordnung? [j/N] :j
Lade Pakete herunter:
Führe rpm_check_debug durch
Führe Verarbeitungstest durch
Verarbeitungstest erfolgreich
Führe Verarbeitung durch
Installieren : rocketchat-0.0.45.0-1.noarch 1/1
Installing npm modules for RocketChat - this may take a while
/var/tmp/rpm-tmp.jHi2bA: Zeile 5: npm: Kommando nicht gefunden.
/var/tmp/rpm-tmp.jHi2bA: Zeile 6: npm: Kommando nicht gefunden.
No rocketchat service. You may need smeserver-rocketchat installed
Verifying : rocketchat-0.0.45.0-1.noarch 1/1
Installiert:
rocketchat.noarch 0:0.0.45.0-1
Komplett!
"Kommando nicht gefunden." - means command not found...
-
Sorry. That is because the 2 rpms are not in my repo yet.
wget both then do
yum localinstall smeserver-rocketchat rocketchat
-
yum localinstall smeserver-rocketchat rocketchat
Just as an aside, "yum localinstall" is deprecated and hasn't been needed for some time--you can just use "yum install" for local RPMs.
-
Thanks Dan I wasn't aware of that !!
Sorry.... am laid up as I put my back out yesterday so sitting/standing are not pleasant.
Will do what I can.
B. Rgds
John