# Setting up a bastion server to debug Instana agent --- Some context first --- - installed Instana agents on SFCC instances weren't running. - agents installed in SFJC instances were running fine. - SFCC & SFJC have similar architecture. --- # WHYYYYY???? - isn't it working for SFCC... --- # Let's SSH into the instance - and find out --- # Oh but they're behind VPC ___ - which means you can't connect to it without doing something that isn't the best practice - whitelisting your IP address to the instance SG temporarily - **NOT forgetting** to remove it after --- - we've been also talking about configuring a bastion host as a bridge to access the instances behind VPC (good practice) for some time now --- - motivated to do this NOW as a solution for the long run --- documented in [Rocketeers wiki](https://rocketeers.atlassian.net/wiki/spaces/GREENPRODUCT/pages/700743936/How+To+SSH+into+SFCC+instances+via+a+Bastion+server)  --- Resources - https://vaughanj10.github.io/creating-a-bastion-host-for-aws/ - https://aws.amazon.com/blogs/security/securely-connect-to-linux-instances-running-in-a-private-amazon-vpc/ --- # So why was the Instana agent not running for SFCC again? --- ``` function start_agent() { ... if [ "$INIT" = "systemd" ]; then ...start agent else log_warn "Instana agent automatic enable/startup by this script is only supported for systemd" log_warn "Utilize your distribution's init system methods to enable/start the agent" fi } ``` --- After figuring that out, we just needed to change the startup script to ``` service instana-agent start ``` --- Disclaimer - Instana did mentioned this in their documentation somewhere  ---