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
Related
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.
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
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.
I have heroku toolbelt installed on Windows7 (x64 HomeEd). When i'm trying to login to heroku, i recieve strange message about MySQL (though MySQL already works fine with all software installed):
Microsoft Windows [Version 6.1.7601]
(c) Microsoft Corp., 2009. All rights reserved.
C:\windows\system32>heroku login
"MySQL" is not recognized as an internal or external command,
operable program or batch file.
"MySQL" is not recognized as an internal or external command,
operable program or batch file.
C:\windows\system32>
Exactly like shown - two times. As I found, heroku.bat does not invoke MySQL at any step. I think that OS runs some script (a kind of autoexec) just before or in parallel with heroku.bat, but i can't find the way used to do this. This is confirmed by the fact that when i start the other bat files the same two messages about MySQL appears.
Can you help me find how that strange script is invoked?
Detailed research shown that the reason is MySQL component, named "MySQL Fabric 1.5.3 & MySQL Utilities 1.5.3 1.5". During installation MySQL added it's location to Path environment variable. This caused to break Path variable contents with "&" symbol and any invocation of Path variable cause error
It seems that at some point a script tries to call MySQL.exe and this file can't be found. To solve this problem you should add the Directory containing MySQL.exe to %PATH%. First make sure MySQL.exe is located on your system. If you are not sure where it is, start CMD, go to your root directory (CD \) end enter dir /S MySQL.exe. This will search your drive for the file and show you the path, where it can be found. Save the path somewhere.
Now that you know where the file is is, you have to add it's location to %PATH%. To do so enter setx PATH "<NEWPATH>;%path%;" where is the path to the directory containing MySQL.EXE. Dont forget ;%path%;, this is very important. If you don't put it there it wil mess up your %PATH%.
Close the console, open a new one and type heroku login. This should fix the problem.
Now if you are not interested in fixing the error and just want to know where it comes from, you should post the code of the batch file that is executed by calling heroku login.
Just remove the C:\Program Files (x86)\MySQL\MySQL Fabric 1.5 & MySQL Utilities 1.5\;C:\Program Files (x86)\MySQL\MySQL Fabric 1.5 & MySQL Utilities 1.5\Doctrine extensions for PHP\; from your path (It is breaking things up, it gets added during MySQL installation)and add the MySQL bin path. For me it is C:\Program Files\MySQL\MySQL Server 5.7\bin
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.