Brenda Logs

[dalekurt]

Hi James,

I'm having a challenge locating the log files for brenda on the nodes.

[Berryu]

When running the instances, type

brenda-tool ssh tail log

[aliasguru]

I've got a very similar issue.

Basically, when I run the brenda-tool ssh tail log command, it IS executed on each instance, but each instance returns the same error to me: bash: log: command not found

Even when I ssh to a particular instance and run the command tail log there, the error persists. It might simply be that the location of logs has changed, or a command isn't available in recent Ubuntu distros, I don't know.

[aliasguru]

Never mind, just found it: The command shall slightly change to brenda-tool ssh tail /mnt/brenda/log

Seems like on every instance, brenda mounts a drive on /mnt/brenda for me and puts the logfile there. I'm using a custom AMI by the way, created based on Ubuntu 14.04.

[woutervddn]

At my end, everthing works as expected.

@aliasguru: It indeed mount to /mnt/brenda, but normally it should create symlinks ln -s /mnt/brenda/ /root/.

Since brenda SSH commands are executed as root, you should be able to view them in as tail log. So either your machine does not act as root, or something goes wrong when the symlink is created, or your SSH 'start' directory is not /root. If you start in / it might explain why it doesn't show up.

Are you using your own AMI? If so, on which distro is it based? What is that distro's default starting dir when connecting to it via ssh?

[aliasguru]

@woutervddn As mentioned above, I created my own AMI and used Ubuntu 16.04 as a base (I misremembered the OS version in my post above, just checked it now). In that instance, I have to use the user ubuntu to log in. What I did in the end was to generate a symlink via sudo ln -s /mnt/brenda/log ~/log to be able to use the brenda-tool command as indicated, and created an AMI afterwards. This works fine now.

[woutervddn]

@aliasguru In Ubuntu 16.04 logging in as Root over ssh is disabled. Even when you enable it, it will still cease to work whenever you restart (or spawn) the machine. This behavior is due to AWS's configuration in /etc/cloud/cloud.cfg. This can be changed by following the procedure written here: http://serverfault.com/questions/412113/aws-how-to-stop-cloud-init-from-disabling-root-login

The code seems to check a disable_root boolean configuration value, so I'm guessing that you need to set this in /etc/cloud/cloud.cfg: disable_root: 0

Took me a couple hours (and about 10 AMI iterations) to figure it out...

[aliasguru]

this works great, thanks for the tip! I was using disable_root: false, as the initial line was disable_root: true, but besides that, login now works as it should! Thanks again!