Taco, Thank you for the info, a little different as I used the ISO images from BO, but as Chris mentioned I will look at the tools (which could be something similar to your situation) and in light of Michael's suggestion with the network config files (which was in the back of my head but just still have not got round to it... life gets in the way... __
Well at least it is now documented in case someone has the same issue, there may be more info added that may make it easier for the next person searching for it... __ Regards Brian On 7/10/2023, 12:23 am, "Blueonyx on behalf of Taco Scargo via Blueonyx" <blueonyx-boun...@mail.blueonyx.it <mailto:blueonyx-boun...@mail.blueonyx.it> on behalf of blueonyx@mail.blueonyx.it <mailto:blueonyx@mail.blueonyx.it>> wrote: Hi guys, I have actually seen this happen on a specific poster/cloud provider. What that provider does is actually overwrite the settings from the hypervisor side. Every time I reboot such a machine, I need to login to the console to restart the network script to properly set the default gateway. Both machines that experience this behaviour were “normal” Linux images provided by the provider, and had BlueOnyx installed manually. Best regards, Taco > On 6 Oct 2023, at 14:05, Chris Gebhardt - VIRTBIZ Internet via Blueonyx > <blueonyx@mail.blueonyx.it <mailto:blueonyx@mail.blueonyx.it>> wrote: > > > 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 <mailto:Blueonyx@mail.blueonyx.it> > http://mail.blueonyx.it/mailman/listinfo/blueonyx > <http://mail.blueonyx.it/mailman/listinfo/blueonyx> _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it <mailto:Blueonyx@mail.blueonyx.it> http://mail.blueonyx.it/mailman/listinfo/blueonyx <http://mail.blueonyx.it/mailman/listinfo/blueonyx> _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
