I inherited an ejabberd installation from a previous employee. Basic commands return
Error command 'xxxx' not known
The doc refers to /etc/ejabberd.cfg, which does not exist on the server. /opt/ejabberd-15.03/conf/ejabberd.yml seems to contain all pertinent configs, such as LDAP and ssl certificate locations.
Everything seems to be running fine for the users, so maybe I'm doing something wrong. Here are some samples:
[root#jabber bin]# pwd
/opt/ejabberd-15.03/bin
[root#jabber bin]# ./ejabberdctl create_room SteveTest conference.localhost localhost
Error: command "create_room" not known.
[root#jabber bin]# ./ejabberdctl muc_online_rooms global
Error: command "muc_online_rooms" not known.
Configuration file
The doc refers to /etc/ejabberd.cfg, which does not exist on the server. /opt/ejabberd-15.03/conf/ejabberd.yml seems to contain all pertinent configs, such as LDAP and ssl certificate locations.
The location of the configuration file is specific to the way ejabberd got installed, so having it in /opt/ejabberd-15.03/conf/ should be fine.
The reason for ejabberd.cfg vs. ejabberd.yml is that ejabberd 13.10 introduced YAML as configuration file format (ejabberd.yml) and deprecated the previously used Erlang terms based one (ejabberd.cfg). From their documentation:
In previous ejabberd version the configuration file should be written in Erlang terms. The format is still supported, but it is highly recommended to convert it to the new YAML […]
ejabberdctl
When you run ejabberdctl without any arguments it should show you all supported commands.
The ones you tried (create_room and muc_online_rooms) shouldn't be in the list, as they are part of the mod_muc_admin module, which got introduced with ejabberd 15.04, but you appear to be running the older ejabberd 15.03.
To get these commands you can either upgrade ejabberd, which would be the recommended way, or fetch the mod_muc_admin module from the ejabberd-contrib repository, which contains third-party ejabberd modules. mod_muc_admin was part of this repository before it became directly included into ejabberd. Here is a link to the last revision of ejabberd-contrib which still contains the module: https://github.com/processone/ejabberd-contrib/tree/e5336f/mod_muc_admin
Related
I am trying to use HSQLDB in server mode, but cannot get the ACL to work.
I started a server (creating a fresh database) with this command line:
java -cp $CLASSPATH:/usr/share/java/hsqldb.jar org.hsqldb.server.Server --database.0 file:~/workspaces/foo/db/fooserver --dbname.0 fooserver
I can connect to it with HSQL Database Manager and issue a SHUTDOWN.
Next, I created an ACL file in ~/workspaces/foo/db/fooserver.acl with the following content:
deny 127.0.0.1
I sucessfully tested it with java -cp $CLASSPATH:/usr/share/java/hsqldb.jar org.hsqldb.server.ServerAcl ~/workspaces/foo/db/fooserver.acl, and it tells me 127.0.0.1 is denied access.
Now I created ~/workspaces/foo/db/server.properties (as there was no server.properties file yet) with the following content:
server.acl=traffserver.acl
However, when I now launch the server, I can still connect to the database.
HSQLDB version is 2.4.1, as shipped with Ubuntu 18.04.
Other things I have tried:
This mailing list post suggests using server.acl_filepath instead of server.acl. Behavior is still the same.
I have tried adding either property to fooserver.properties. Still no effect, and the property gets deleted when I stop the server.
What am I missing?
First of all, if you use a server.properties file which is not located in the directory where you execute the java command, you should include the path to that properties file.
In the same scenario, in the server.properties file, you need to use the same path as you successfully tested. So it should be:
server.acl=~/workspaces/foo/db/fooserver.acl
It would be easier to specify the properties and acl files if you issue the java command from the directory that contains both files. In that case you can use a short filename instead of the full path.
See the Guide http://hsqldb.org/doc/2.0/guide/listeners-chapt.html
I want to use dovecot as a local IMAP server to serve my offlineimap synced mails to gnus. This is on a Nixos installation. I have installed the dovecot package via my configuration.nix. however I am having trouble configuring it, seeing where the log files are, etc. I copy the configuration files (dovecot.conf and config.d) from /nix/store/dovecot/share/doc/dovecot/example-config. I can then modify slightly the files to allow plain login (no ssl required) just to test.I can start dovecot (as root). I see the process running, the relevant ports are open and listening, e.g. 143. Everything looks OK. No crashes. However when I telnet localhost 143 (for imap) to test, I am connected and then immediately the connection is closed by foreign host. This is not what I expect from the Dovecot Wiki. I should get a statement that Dovecot is ready …
Additionally, the command doveadm log find responds with:
Looking for log files from /var/log Debug: Not found Info: Not found etc.
So there seem to be no log files. journalctl -u dovecot2.service shows logs begin …, end at …
No entries, so no issues ? I cannot find a log file which tells me why the connection on 143 is immediately closed.
I am at a loss what is going on. Is it to do with users needed, etc ? Appreciate any help. Can post doveconf -n if needed.
As written in the configuration file for dovecot2 here: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/mail/dovecot.nix#L344 as dovecot2 is the name of the service journalctl -u dovecot2 should be the right command to run to view its logs. That said, if for some reason there's a bug in the configuration module the command journalctl will show you the complete log, dovecot's included.
It would be nice if you had written here your configuration, because given that the configuation entries for dovecot are those listed here https://nixos.org/nixos/options.html#services.dovecot2 it's not clear to me what you mean when you write ... I copy the configuration files (dovecot.conf and config.d) from /nix/store/dovecot/share/doc/dovecot/example-config ... The configuration in nixos is comprised for the most part of Nix source files that specify entries in the NixOS configuration tree I've linked before.
I was doing things completely wrong. I now specify the dovecot service to start in my configuration.nic file and it sets up the correct environment with all config files in their correct place. To change options in the config file, e.g maildir, I now specify them also in the configuration.nix file. Thanks for your answer.
How can I get ejabberd to run an external auth script on windows?
So far- I've modified the file
C:\Program
Files\ejabberd-15.06\lib\ejabberd-15.06\priv\cfg\ejabberd.yml
to comment out the existing auth_method directive and instead added this:
auth_method: external
extauth_program: "D:\\DROPBOX\\Dropbox (Personal)\\EJABBERD\\auth\\ejabberd-auth.exe"
However, when I try to connect to the server- I see nothing in the logs indicating an attempt to run the script. I've even tried changing it to a non-existant file to see if that will log an error of some sort, but nothing.
All I get are "Accepted connection" type of logs.
In case it matters- upon start I do get several "unknown option" errors, including "ejabberd_config:validate_opts:752 unknown option 'auth_method' will be likely ignored" - however it seems this is a known, cosmetic-only error (see: https://github.com/processone/ejabberd/issues/630)
I do not use Windows, but, you should try playing with Erlang open_port command:
open_port({spawn, "YOURCOMMAND"}, [{packet, 2}]).
Note that open_port Erlang documentation says:
For external programs, the PATH is searched (or an equivalent method is used to find programs, depending on operating system). This is done by invoking the shell on certain platforms. The first space separated token of the command will be considered as the name of the executable (or driver). This (among other things) makes this option unsuitable for running programs having spaces in file or directory names.
I see your path has spaces. That alone should indeed make it impossible to call your command.
That said, external_auth command has never been tested on Windows. You may need to patch ejabberd command to make that authentication through external process work. I would be surprised if it works as is.
My objective: get https://github.com/couchbaselabs/ToDoLite-iOS syncing with a Couchbase Server and sync gateway on localhost rather than the default demo URL.
I run sync gateway like so: bin/sync_gateway -url http://localhost:8091
And then the only thing I changed in the example is:
-#define kSyncGatewayUrl #"http://demo.mobile.couchbase.com/todolite"
+#define kSyncGatewayUrl #"http://localhost:4984/sync_gateway/"
And when I run
Error: Error Domain=CBLHTTP Code=404 "404 not_found" UserInfo=0x7ff11941fb50 {NSURL=http://localhost:4984/sync_gateway/_facebook, NSLocalizedFailureReason=not_found, NSLocalizedDescription=404 not_found}
How do I fix this?
I solved it. The reason is that I ran sync_gateway without enabling Facebook registration support.
Normally this is done in config.json file. In fact, this configuration file was supplied in ToDoLite all along.
It is crucial that you launch sync_gateway with this configuration file. The README actually states this but in a loose and casual way...
cd ToDoLite-iOS
sync_gateway -url http://localhost:8091 sync-gateway-config.json
NB: I assume above that sync_gateway has been made accessible through $PATH. It's a good idea to do that anyway.
Also, I didn't pay attention to the dbname. So you'll need to replace
#define kSyncGatewayUrl #"http://demo.mobile.couchbase.com/todolite"`
with
#define kSyncGatewayUrl #"http://localhost:4984/todos"
So, what's the complete sequence of steps to get it working?:
If you want to wipe everything on the server, rm -rf Library/Application\ Support/Couchbase and start over. Homebrew cask hides this setting somewhere else where it's hard to reset so a manual install is very recommended.
Install Couchbase Server
Set up login credentials if fresh install; otherwise just login
Create a bucket (a database) with name todos on the cluster. This is the dbname used by TODOLite.
Launch sync gateway. Be sure to pass in the replication URL AND the JSON config file.
bin/sync_gateway -url http://localhost:8091 sync-gateway-config.json; keep sync gateway running
In the TODOLite AppDelegate.m, change kSyncGatewayUrl:
#define kSyncGatewayUrl #"http://localhost:4984/todos". Notice the name of the database is necessary!
(Optionally) Access the administrator interface of the sync gateway by going to http://localhost:4985/_admin/db/sync_gateway/sync. You can set up the sync function here.
In case you're wondering where those port numbers came from, check out
ports Couchbase Server uses
ports Sync Gateway uses
4984 — SG API port
4985 — SG admin server
The default remote sync URL will be defined in different files depending on the version of the project you download (iOS, Android, PhoneGap, and Motion). To find the appropriate string to change simply search through your project for the URL "http://demo.mobile.couchbase.com/todolite" and replace it with the URL of your new sync gateway database.
I've successfully installed MySQL 5.6 on my F19. Although the installation was successful, I'm unable to start the mysql service.
When I ran
service mysql start
It returns the following error:
Starting MySQL..The server quit without updating PID file (/var/lib/mysql/sandboxlabs.pid).
I disabled SELinux (permissive mode), and the service started smoothly. But I did some research about disabling SELinux, and found that disabling SELinux is a bad idea. So, is there any way to add custom MySQL policy? Or should I leave the SELinux to permissive mode?
The full answer depends on your server configuration and how you're using MySQL. However, it's completely feasible to modify your SELinux policy to allow MySQL to run. In most cases, this sort of operation can be performed with a small number of shell commands.
Start by looking at /var/log/audit/audit.log. You can use audit2allow to generate a permission-granting policy around the log messages themselves. On Fedora 19, this utility is in the policycoreutils yum package.
The command
# grep mysql /var/log/audit/audit.log | audit2allow
...will output the policy code that would need to be compiled in order to allow the mysql operations that were prevented and logged in audit.log. You can review this output to determine whether you'd like to incorporate such permissions into your system's policy. It can be a bit esoteric but you can usually make out a few file permissions that mysql would need in order to run.
To enable these changes, you need to create the policy module as a compiled module:
# grep mysql /var/log/audit/audit.log | audit2allow -M mysql
...will output the saved plaintext code to mysql.te and the compiled policy code to mysql.pp. You can then use the semodule tool to import this into your system's policy.
# semodule -i mysql.pp
Once you've done this, try starting mysqld again. You might need to repeat this process a few times since mysqld might still falter on some new access permission that wasn't logged in previous runs. This is because the server daemon encounters these permission checks sequentially and if it gets tripped on one, it won't encounter the others until you allow access to the initial ones. Have patience -- sometimes you will need to create mysql1.pp mysql2.pp mysql3.pp ... and so on.
If you're really interested in combining these into a unified policy, you can take the .te files and "glue" these together to create a unified .te file. Compiling this file is only slightly more work -- you need the Makefile from /usr/share/selinux/devel/Makefile in order to convert this into a .pp file.
For more information:
If you're a more graphical type, there's also a great article by RedHat magazine on compiling policy here. There's also a great blog article which takes you through the creation of a policy here. Note the emphasis on using /usr/share/selinux/devel/Makefile to compile your own .te, .fc, and .if files (selinux source written in M4).