Anchor wont boot after unusual activity in root's .bash_history
We host an anchor that went offline on Sept 1, 2026. During troubleshooting, I noticed the following in root's .bash_history:
ping pl-szz-as28785.anchors.atlas.ripe.net tail -f /var/log/ansible.log yum -y update reboot cat /etc/redhat-release dd if=/dev/zero of=$(mount|grep boot|awk '{print $1}') rm -rf /etc/ /home/ /srv/ /export/ systemctl poweroff
Indeed, the boot partition is corrupted, grub can't identify any filesystem on it, nor can any other file system tools. From the messages, I can see that a named user from RIPE (meaning, it didn't appear to be an automated login) was logged in at this time. I opened a ticket in the portal on September 11 and have not received an update, nor can I open a second ticket on the same node. Before I begin to reinstall or recover this node, I'd like to know what's going on. Has anyone else seen anything like this? -- ________________________________ Andrew Gallo The George Washington University
Hi Andrew, Apologies for the troubles with your Anchor. The history content is our decommissioning playbook; though I do see that pl-szz-as28785.anchors.atlas.ripe.net is online and connected to Atlas, is there a different Anchor that was powered off in this way? Would you also mind sharing the ticket numbers with me? Happy to help get your Anchors back online if they were unnecessarily decommissioned. Thanks for hosting, Sean Mottles RIPE NCC On Wed, 30 Sept 2026 at 16:18, Andrew Gallo via ripe-atlas < ripe-atlas@ripe.net> wrote:
We host an anchor that went offline on Sept 1, 2026. During troubleshooting, I noticed the following in root's .bash_history:
ping pl-szz-as28785.anchors.atlas.ripe.net tail -f /var/log/ansible.log yum -y update reboot cat /etc/redhat-release dd if=/dev/zero of=$(mount|grep boot|awk '{print $1}') rm -rf /etc/ /home/ /srv/ /export/ systemctl poweroff
Indeed, the boot partition is corrupted, grub can't identify any filesystem on it, nor can any other file system tools.
From the messages, I can see that a named user from RIPE (meaning, it didn't appear to be an automated login) was logged in at this time.
I opened a ticket in the portal on September 11 and have not received an update, nor can I open a second ticket on the same node.
Before I begin to reinstall or recover this node, I'd like to know what's going on. Has anyone else seen anything like this?
-- ________________________________ Andrew Gallo The George Washington University
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Thank you, Sean. I didn't get the ticket number through the portal. I sounds as if this is was expected behavior, maybe just one the wrong node, which puts my mind at ease! I'll share details directly. Thank you. On 9/30/2026 10:41 AM, Sean Mottles wrote:
Hi Andrew,
Apologies for the troubles with your Anchor. The history content is our decommissioning playbook; though I do see that pl-szz-as28785.anchors.atlas.ripe.net is online and connected to Atlas, is there a different Anchor that was powered off in this way? Would you also mind sharing the ticket numbers with me? Happy to help get your Anchors back online if they were unnecessarily decommissioned.
Thanks for hosting, Sean Mottles RIPE NCC
On Wed, 30 Sept 2026 at 16:18, Andrew Gallo via ripe-atlas < ripe-atlas@ripe.net> wrote:
We host an anchor that went offline on Sept 1, 2026. During troubleshooting, I noticed the following in root's .bash_history:
ping pl-szz-as28785.anchors.atlas.ripe.net tail -f /var/log/ansible.log yum -y update reboot cat /etc/redhat-release dd if=/dev/zero of=$(mount|grep boot|awk '{print $1}') rm -rf /etc/ /home/ /srv/ /export/ systemctl poweroff
Indeed, the boot partition is corrupted, grub can't identify any filesystem on it, nor can any other file system tools.
From the messages, I can see that a named user from RIPE (meaning, it didn't appear to be an automated login) was logged in at this time.
I opened a ticket in the portal on September 11 and have not received an update, nor can I open a second ticket on the same node.
Before I begin to reinstall or recover this node, I'd like to know what's going on. Has anyone else seen anything like this?
-- ________________________________ Andrew Gallo The George Washington University
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-- ________________________________ Andrew Gallo The George Washington University
participants (2)
-
Andrew Gallo -
Sean Mottles