Re: [gentoo-user] Re: New Intel CPU flaws discovered
> > > The classic one is where OPS haven't noticed that disks in a RAID array > have died years ago... > > This really happened? > Yeah. Spent huge money on NMSes but then didn't spend the relatively small amount on thorough integration to make it really worthwhile... It seems common to me that companies penny pinch too hard and shoot themselves in the foot. Probably due to perverse incentives and/or the inability to capture true value on a ledger. It requires leadership.
Re: [gentoo-user] Re: New Intel CPU flaws discovered
> On May 17, 2019, at 01:14, Adam Carter wrote: > > The classic one is where OPS haven't noticed that disks in a RAID array have > died years ago... This really happened?
Re: [gentoo-user] Re: New Intel CPU flaws discovered
> > something even worse. Since rebooting is when those tend to > fail/break/whatever, it is yet another reason I avoid rebooting. I take the opposite approach. If I update the kernel and reboot often, I see the following benefits; - Each increment in version is smaller, therefore there's less change per update, which make it easier to troubleshoot if there's problems - Doing something regularly is practice, and practice makes perfect. If you were to update regularly you would become more proficient and confident with doing the init thingy (initrd?) - If a hardware issue occurs, I find it at a good time when i'm not busy, and have the time to troubleshoot - Getting the benefits of the automated kernel code testing (eg syzbot, KASAN) that is used these days finding issues that then get fixed (including security issues). You'd have to assume that over the overall quality of the kernel is improving at a faster rate now than before those extra checks were in place. At work I have raised tickets to have systems with big uptimes have their hardware status reviewed then restarted, a couple of days before I undertake risky/critical work. That way I can have more confidence in the system's health before starting. The classic one is where OPS haven't noticed that disks in a RAID array have died years ago... Even when I have a power fail here, it makes me very nervous to shutdown. > Another benefit of regular updates would be to reduce stress of deciding to shutdown, as you will have more confidence that the systems are healthy when you need to do it. :)
Re: [gentoo-user] requirement: ssh v1
On Thu, May 16, 2019 at 6:45 AM Stefan G. Weichinger wrote: > > > At a customer we still have to keep up an ancient Suse 6.x VM, it has a > legacy and proprietary software in it which has to be kept alive. > > No way to move that sw to another OS, don't ask ... > Any chance to just attach to the VM console, or a serial console on that VM tied it back to a serial console on another host that runs modern tools, taking the SSHv1 offline? It's providing more vulnerability than it is security. -- Poison [BLX] Joshua M. Murphy
Re: [gentoo-user] requirement: ssh v1
On Thu, May 16, 2019 at 8:09 AM Michael Orlitzky wrote: > > Otherwise, your best bet is to install a modern Gentoo system, and then > downgrade OpenSSH. > ++ assuming it builds, which it probably would. I'd just stick the old ebuild in an overlay and mask out the gentoo repo for that package (I assume mask atoms can take a repo name). If the old openssh doesn't build then you're going to have a more difficult situation. A container does seem like a reasonable solution for this, if you're just doing this for the ssh client. You could also just use a chroot, though these days I have completely replaced chroots with containers as the latter are almost universally better. -- Rich
Re: [gentoo-user] requirement: ssh v1
Am 16.05.19 um 14:09 schrieb Michael Orlitzky: > On 5/16/19 6:44 AM, Stefan G. Weichinger wrote: >> >> Will I be able to install such a "kept old" gentoo machine from scratch >> or does some have a better idea? >> > > Does it *need* SSHv1, or does the default sshd *run* SSHv1? It *is* SSHv1 ... v2 didn't exist back then ;-) > If it's the latter, you might be able to compile a newer OpenSSH from > source to get the modern protocol, obviating the need for the extra host. > > Otherwise, your best bet is to install a modern Gentoo system, and then > downgrade OpenSSH. I setup a small VM with debian 8 ... seems to work. thanks, sorry for the noise
Re: [gentoo-user] requirement: ssh v1
On 5/16/19 6:44 AM, Stefan G. Weichinger wrote: > > Will I be able to install such a "kept old" gentoo machine from scratch > or does some have a better idea? > Does it *need* SSHv1, or does the default sshd *run* SSHv1? If it's the latter, you might be able to compile a newer OpenSSH from source to get the modern protocol, obviating the need for the extra host. Otherwise, your best bet is to install a modern Gentoo system, and then downgrade OpenSSH.
[gentoo-user] requirement: ssh v1
At a customer we still have to keep up an ancient Suse 6.x VM, it has a
legacy and proprietary software in it which has to be kept alive.
No way to move that sw to another OS, don't ask ...
That VM only runs sshd v1 ... so far I kept my openssh package on the
host at 7.5 via masking ...
I now have to replace the gentoo server and set up the vitualization
host with debian ("don't ask" again ;-)).
I think of setting up a tiny gentoo VM as a "jumphost" into the Suse VM.
Will I be able to install such a "kept old" gentoo machine from scratch
or does some have a better idea?
I even thought of docker ...
