On 10/5/23 8:54 PM, Michael Stauber via Blueonyx wrote:
I can't imagine a way how the network settings would switch to DHCP on
their own. So I'm as confused as you are why this has happened in your
case.
We've set up and operated hundreds of BlueOnyx servers of every version
since its inception, with BlueQuartz and Cobalts before that. (We won't
get into the couple of dalliances with the likes of TurboLinux) and have
NEVER seen this happen. Not in a quarter-century of use, and even in
some "alternative" configurations.
I would suggest that this type of change would be deliberate. Is this
system perhaps assigned to a dedicated user who may have made this
change by mistake / not knowing any better? We've certainly seen end
users get things mangled.
You mention it's a virtual machine, so I'm also curious which hypervisor
you're using and would its toolkit have tried to "help" you out by
making the change. (We've never seen that happen with VMware products
or Aventurin{e} or ProxMox.)
Also... why is it picking up DHCP in the first place? Why is there a
DHCP server on your public network? I would absolutely recommend
locking that down and placing your resources into proper pools /
VLANs. There should not be a chain of events that would have a DHCP
server suddenly appear on a production hosting network.
There may be a way to use RPM/YUM to re-install the networking
components from stock. I'd defer to Michael on that one. Or you may
want to consider spinning up a replacement and using EasyMigrate to hop
over. If it was me in your shoes, though, I would hesitate to do that
without fully understanding the chain of events that caused the issue in
the first place. After all, if it happened once, it's certainly
reasonable to expect it could happen again.
My suggested steps in any case would be:
1. Fix the network. Your public hosting needs to be completely
segregated from other traffic. DHCP doesn't belong there.
2. Evaluate the security policy that allowed DHCP on your hosting
network in the first place and install safeguards as necessary.
3. Evaluate the users on the system that went haywire. If there are
admin/root permissions in another user's hands, could they have made
this change, even if completely by accident or without understanding
their actions? Have you dumped / reviewed the bash history? Not
foolproof but helpful in some cases... Lock out / lock down any users
who have root/admin but don't NEED it.
4. Once above conditions are satisfied (at least, as best as possible)
evaluate if system is trustworthy/stable. If so, continued operations
on the server may be fine, especially if you are able to locate &
address the root cause(s). If not, consider replacing the server,
limit access and in any event monitor closely (set alerts for logins, etc).
HTH,
--
Chris Gebhardt
VIRTBIZ Internet Services
Access, Web Hosting, Colocation, Dedicated
www.virtbiz.com | toll-free (866) 4 VIRTBIZ
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx