Cronicle Master tries to communicate with the cronicle slave on Private IP and effectively communication fails about cronicle HOT 19 CLOSED

Any update ?

from cronicle.

Try this:

https://github.com/jhuckaby/Cronicle#server_comm_use_hostnames

server_comm_use_hostnames

Setting this parameter to 1 will force the Cronicle servers to connect to each other using hostnames rather than LAN IP addresses. This is mainly for special situations where your local server IP addresses may change, and you would prefer to rely on DNS instead. The default is 0 (disabled), meaning connect using IP addresses.

You may also need this one, depending on how your local machines connect to your network:

web_socket_use_hostnames

Setting this parameter to 1 will force Cronicle's Web UI to connect to the back-end servers using their hostnames rather than IP addresses. This includes both AJAX API calls and Websocket streams. You should only need to enable this in special situations where your users cannot access your servers via their LAN IPs, and you need to proxy them through a hostname (DNS) instead. The default is 0 (disabled), meaning connect using IP addresses.

from cronicle.

Thanks, jhuckaby. Will try that.
Do we need to update this in all master and slave Cronicles ?
Do we need to restart Cronicle after the modification ?

from cronicle.

Yes, all your servers should have the same exact configuration settings. Yup, this change requires a restart.

from cronicle.

I see the variables are already set to 1 in both master and slaves:
"server_comm_use_hostnames": 1,
"web_socket_use_hostnames": 1,

from cronicle.

config.json is synched between the master and the slave servers .
Are we still missing something that is forcing the master server to use IP instead of hostname

from cronicle.

Oh crap!! I see the problem here:

https://github.com/jhuckaby/Cronicle/blob/master/lib/job.js#L1123-L1124

This bit of code constructs the URL to fetch the job log, and it always uses the IP address. It doesn't honor the server_comm_use_hostnames setting. GAH!!

So sorry. I will get this fixed as soon as possible, and release a new version.

Thanks for reporting this!

from cronicle.

Let me try it.

from cronicle.

Please let us know when fixed. So we can update the Cronicle

from cronicle.

Looks like this issue is related to #26 and @jhuckaby the same fix should at least partially resolve that as well.

from cronicle.

Should be fixed in v0.6.16:
https://github.com/jhuckaby/Cronicle/releases/v0.6.16

Thanks for reporting this!

from cronicle.

Thanks @jhuckaby will roll out the fix.

from cronicle.

from cronicle.

@jenkins-deployer-cpi This is a completely different problem than the one you described before. This looks like a permission issue on your server. Did you start Cronicle as a non-root user? It doesn't have permissions to spawn a child process, which is highly irregular (root should have full permissions).

Make sure you become the superuser (root) or use "sudo" when starting Cronicle.

from cronicle.

from cronicle.

Whatever user you are running Cronicle as doesn't have permissions to launch the executable that is listed in your event or Plugin.

This is not an issue in Cronicle itself, but rather just a Node.js / Linux thing. Whatever process you are trying to launch in your event either doesn't have "execute" permissions (e.g. chmod a+x /path/to/executable), or the user itself doesn't have access to read the file / script executable.

Or it could be that the user Cronicle is running as doesn't have execute permissions to any of the parent directories outside the executable you are trying to launch.

Running Cronicle as root would also solve this.

from cronicle.

from cronicle.

Okay, I found more information. You didn't say that you were using the Shell Plugin (I don't have any information about your setup, nor your logs or config files, so I have to largely guess what is going on here). I can see in the stack trace that we are getting a failure inside the Shell Plugin right here:

	var script_file = path.join( os.tmpdir(), 'cronicle-script-temp-' + job.id + '.sh' );
	fs.writeFileSync( script_file, job.params.script, { mode: "775" } );
	
	var child = cp.spawn( script_file, [], { // CRASH HERE WITH EACCESS ERROR
		stdio: ['pipe', 'pipe', fs.openSync(job.log_file, 'a')] 
	} );

The Shell Plugin works by taking your shell script code (text) from the event and writing it out to a file in the server's temporary directory, setting its permissions to 0755, then spawning it. This is failing on your server, due to the permissions of the user you are running Cronicle as.

So your Cronicle user doesn't have access to the server's temporary directory (whatever Node.js returns from os.tmpdir()).

If you want to find out what Node.js is using as the temp dir, run this command (run it as the Cronicle user for most accurate results):

node -e 'console.log(require("os").tmpdir());'

Whatever that command outputs on your server is the directory Node.js is using to write temporary shell script files and then trying to execute (spawn) them.

You need to change your Linux server settings so that whatever user you are using to run Cronicle as has both read and execute permissions in this directory, and all of its parent directories.

Note that this issue has nothing to do with issue #29, nor the upgrade to fix it, and is a completely different problem altogether.

from cronicle.

Thanks

from cronicle.