Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple conmand daemons connecting to the same consoles #22

Open
kcgthb opened this issue Oct 23, 2015 · 3 comments
Open

Multiple conmand daemons connecting to the same consoles #22

kcgthb opened this issue Oct 23, 2015 · 3 comments
Labels

Comments

@kcgthb
Copy link

kcgthb commented Oct 23, 2015

Hi,

I'd like to have a redundant setup where multiple conmand daemons running on different machines would log the same consoles.
Say, server1 monitors consoles a and b, server2 monitors the same a and b consoles, and both servers log the consoles' output on their respective local filesystem.

It looks like currently, whatever server starts first gets a hold on the consoles, and the 2nd one doesn't get any output. So if server1 starts first, the consoles' output is correctly stored in server1:[global log]/%N.log, while server2 gets only timestamps.

Would it be possible to log the console outputs in monitor-only mode, so that several conmand daemons could log the output at the same time?

Thanks.

@dun
Copy link
Owner

dun commented Oct 26, 2015

Terminal servers oftentimes allow only one client at a time to connect to a given console. This behavior is specific to your particular setup.

conmand daemons do not currently share any configuration or state information. Support for a redundant configuration as you describe would be a major undertaking.

My initial thoughts for such a design would entail having conmand1 on server1 and conmand2 on server2 communicating with each other. Through some mechanism, one of them (e.g., conmand1) would be elected to have exclusive access to the console. It would relay I/O to the other (conmand2) and/or some external datastore. If conmand1 was to fail, conmand2 would detect this and take over exclusive access to the console. This design also requires the conman client to be able to determine which conmand is currently authoritative for a given console, etc.

I agree it would be a useful feature, but I think it would be a lot of work to implement.

@dun dun added the feature label Oct 26, 2015
@kcgthb
Copy link
Author

kcgthb commented Oct 26, 2015

Hi Chris,
Thanks for considering this.

About simultaneous connection from multiple conmand servers to the same console, wouldn't this be similar to when multiple conman clients connect to the same console? They would use monitor (R/O) mode instead of interactive (R/W) mode, which would be sufficient for logging, wouldn't it?

@dun
Copy link
Owner

dun commented Oct 27, 2015

When multiple conman clients connect to the same console, they are all connecting to the same conmand; that single conmand has exclusive access to the console and arbitrates / multiplexes I/O as needed.

When conmand connects to a given console, it is constrained by the protocol, hardware, firmware, etc. Many console servers only allow a particular console to be accessed by one client at a time. If that client is conmand, then that single conmand can multiplex the I/O to multiple conman clients.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants