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.
Related
Running the Config Wizard via the start menu (Windows 7) simply fails. Running it from the command prompt shows the infamous
'C:\Program' is not recognized as an internal or external command, operable program or batch file
I know this is due to the space in "Program Files" (dir C:\pro* /x doesn't show C:\Progra~1).
The solution I've found for this is to replace C:\Program Files\... with "C:\Program Files\...".
My question is this:
Since the WebLogic config wizard runs from config.cmd, which is loaded with variables for path names, do I have to update Windows system environment variable PATH and put quotes around all path names that have a space (since I don't know what WebLogic is looking for)?
Update:
I tried this and received Files was unexpected at this time. Which made me think I was off with the quotes, but they are paired properly around every path with C:\Program Files. A search on this error resulted with this advice...basically the double quotes are the cause.
If the lack of quotes causes the first problem, and the presence of quotes causes the second problem, what to do? It's a loop...
I installed another JDK in a location with no spaces (still got the error because I didn't change any environment variables because work site will change them back, breaking things).
The install docs in chapter 4 say:
To begin domain configuration, navigate to the
ORACLE_HOME/oracle_common/common/bin directory and start the
Configuration Wizard.
On UNIX operating systems:
./config.sh
On Microsoft Windows operating systems:
.\config.cmd
Which implied at a command prompt (to me anyways). I was reading another site for help and the guy said to update config.cmd to point it to new JDK location instead of JAVA_HOME.
Instead of right clicking on config.cmd to edit it I double clicked it and lo and behold...this nice domain creator GUI opened up where I could specify which JDK to use. Done! No errors...
If that little tidbit were in the docs it would've save me a lot of time and frustration. And no, I'm not a server admin type, just a dev who needed a local web server for testing purposes.
I hope this helps someone.
I am building an installer for our product which works well. I've managed to build custom actions to install our services including a MySQL server.
The problem I have is executing a sql file to build the schema structures.
I have a custom action which uses mysql.exe and the command line arguments:
--port=### --user=### --password=### < "[INSTALLDIR]db\EmptyStruct.sql"
It tries to execute this ok but the cmd window which pops up, during the install, just runs through the mysql.exe command line options, which says to me that the command line it gets passed is not correct. However if I run the command manually after the install, it works perfectly.
Does anyone has any ideas please.
I'm making a few assumptions here:
You have a Windows Installer exe custom action that specifies mysql.exe and a command line as you showed
You are expecting the contents of [INSTALLDIR]db\EmptyStruct.sql to be redirected to mysql.exe's standard input
This will not happen. Behind the scenes, Windows Installer's exe custom action support uses the CreateProcess API and this API will interpret command lines literally. However the redirect < needs special handling to actually perform redirection.
To get that behavior, you must use a layer of indirection. For example, you could run cmd.exe as the exe, and give it a command line that will make it interpret and run the command line mysql.exe --port= ... < "[INSTALLDIR]...". However, if you didn't already have a command prompt showing, this would cause one to show up. If you want to avoid that, you could write a custom wrapper that performs the redirection for you, either as a C++ DLL or, say, InstallScript action.
Alternately, if there is a parameter that tells mysql.exe to run a script from a file, you could pass that instead of using redirection. I wasn't able to find evidence of such a parameter in a quick web search.
Thanks for your comments Michael and I used cmd.exe /k AddStruct.bat to accomplish the task!
We are monitoring our production environments using Zabbix 2.4. New instances are provisioned with Ansible that sets up a Zabbix agent. What we need is for hosts to be removed from the server if they have been terminated so that we only receive messages about running instances becoming unavailable.
To do this I wrote a Python script that can take a zabbix host name as an argument, check if that host is on the list of running instances by calling awscli and delete the host if it's not on a "not terminated" list.
I put the script in /usr/bin/delete_host.py and configured an action to call for it when a "Agent not available" trigger is activated. This is how the Operation tab looks like link
And here is the Action Log link
I've tried a couple of ways to write the command, also placed the script in ExternalScripts directory. Turned on debug logs for the server but nothing in it mentioned an error or anything. In fact it only showed messages that command is being executed and everything is ok, but the host is still there. When I copy the command from Action Log and execute it manually everything works fine.
At this point I am really out of options on how to troubleshoot this further. I disabled selinux and added zabbix user to sudoers file with nopasswd. I can't find anything in any logs. Is it even possible to execute non-messaging scripts with zabbix?
Try to write the script in a way that will print "OK" or 0 if it ran properly and the error message or error code if it fails. Run the script using an active zabbix agent item on the Zabbix server host (use the function system.run). In this way you'll be able to create a trigger that will raise an error if the script fails to run.
You can also just schedule it using a different tool such as Rundeck.
The script does not have to be in the ExternalScripts directory, that is only required for items of type "external check". The operation screenshot you linked to uses relative path of delete_host.py, and that is almost guaranteed not to work. Your action log screenshot shows a few entries with /usr/bin/ prefixed, which is better.
At least for testing, make sure to specify full path to everything, including the python binary, for example /full/path/to/python /full/path/to/delete_host.py.
You also had a few entries that redirected all output to a file in /tmp/, but you didn't mention what got logged in there. Please use that approach and check the potential error messages as well.
Remote commands from "Actions" are run using the key system.run[command,nowait]. This "nowait" key returns 1 irrespective of the command result.
Try running system.run with "wait" parameter and see what the actual error is under "Latest data".
For me the error was "sudo: sorry, you must have a tty to run sudo" even i had "Defaults:zabbix !requiretty" in the sudoers file. I commented out the "#Defaults requiretty" line in /etc/sudoers file and it worked.
I'm trying to use the dbext vim plugin to connect to a MySQL database.
When I give commands like <Leader>se I get an error:
Can't open file
/var/folders/b3/s3wyytf90_ld113h1w3p86ldcg4glv/T/vQ0XMX3/7
That file doesn't exist. But the SQL I expect to be executed does exist in:
/var/folders/b3/s3wyytf90_ld113h1w3p86ldcg4glv/T/vQ0XMX3/dbext.sql
So it looks as if the plugin is writing a temp file in one location and looking for it in another.
I'm sure the plugin can't be broken and I must have done something wrong, but I don't know enough Vimscript to follow it through.
I have Vim v7.3, dbext 20.00 and have just installed by unzipping the plugin zip into my .vim directory.
I've used
:DBPromptForBufferParameters
to set up my connection parameters.
The full error looks like:
dbext: Executing SQL at 13:54
Error detected while processing function dbext#DB_execSql..dbext#DB_execFuncTypeWCheck..<SNR>42_DB_MYSQL_execSql..<SNR>42_DB_runCmd:
line 24:
E484: Can't open file /var/folders/b3/s3wyytf90_ld113h1w3p86ldcg4glv/T/v0BN3Qw/7
Press ENTER or type command to continue
Can anyone point me in the right direction to resolve this?
Edit: I've since tried an install into an empty .vim directory, with all of my other config and plugins removed, so I don't think that it's a case of conflicting configuration.
I'm running MacOSX, in case it's relevant.
Dumb mistake on my part.
I was supplying a bare password which needed to be quoted in this context due to a special character.
I'm now quoting the password when prompted for it by :DBPromptForBufferParameters and everything is working.
If I run Inno Setup compiler from a command line/batch file it creates an exe with the version information in the file name.
However, when I run from hudson (same command line) I don't get the version information.
Perhaps I am missing something.
Is this a known issue?
This is the way I am doing it in the iss script file.
#define FileVerStr GetFileVersion(SrcApp)
EDIT:
The env vars are all set for all users - not just my login - so the service has access to everything that the command line build does.
EDIT: See my answer for a resolution of this.
Like "tim" has said, then relative paths doesn't work as expected for defines.
#define MyAppVer GetFileVersion(SourcePath + "\..\Build\Release\MyExeName.exe")
#if MyAppVer == ""
#error MyAppVer - Version information not found!
#endif
By prefixing with SourcePath then the relative path will start from the path where the InnoSetup-script is located.
You are likely running Hudson on Windows given the technology mentioned.
When there is a discrepancy between what happens on the command line and what Hudson does, it is often because Hudson is running as a service on Windows. This means it is running as the service user, which is distinct from your login account.
I would look for an environment variable that you have defined in your user profile that may enable this behavior, that is not being set for the service user.
I am not exactly sure how to describe how I "fixed" this/worked around it.
It seems the GetFileVersion() method does not use the same base path as the other part of the Inno functionality that determines where the source files/installable files are.
The SAME relative paths used for:
// this is for determining what files get put into the install image
[Files]
Source: ..\Build\ForRelease\MyExeName.exe; DestDir: {app}
and
#define SrcApp "..\Build\ForRelease\MyExename.exe"
#define FileVerStr GetFileVersion(SrcApp)
apparently do not use the same mechanism to resolve the file name/path. So what i did to work around this was to copy the exe file that contains the version info to two additional different locations (aside from ..\Build\ForRelease) - one where hudson starts the processes and also to the path where the inoo script is. (I am too lazy to figure out which one is the one that makes it all work.
Again, this works fine from my batch file but not from hudson. It is essentially a strange interaction with how Inno works I guess.