On 5/28/24 6:54 AM, Roberto Ragusa wrote:
Why is the original poster saying that he is not able to reach the machine
during the upgrade because of inability to fork sshd?
I think you misunderstood. As far as I could tell he didn't have any
issues. It was a theoretical question about
On 5/28/24 09:38, Samuel Sieb wrote:
There is nothing to fix. The ssh process has already loaded the libraries, so
it won't crash if you replace them. After you upgrade the libraries, you just
need to restart it to get the new ones loaded. Any existing connections will
still be processes
On 5/28/24 12:14 AM, Roberto Ragusa wrote:
The interesting topic on the table is the robustness (or lack of)
of the sshd daemon during an upgrade of its binaries and libraries.
That daemon is critical for remotely managed systems and the developers
usually take care of the implementation
On 5/25/24 08:47, Tomasz Torcz wrote:
Dnia Fri, May 24, 2024 at 01:33:44PM +0200, Marius Schwarz napisał(a):
Am 24.05.24 um 12:01 schrieb Roberto Ragusa:
Why can't sshd fork a new instance?
you have ask the sshd devs.
First guess: they do not use fork().
The whole premise of this
Dnia Fri, May 24, 2024 at 01:33:44PM +0200, Marius Schwarz napisał(a):
> Am 24.05.24 um 12:01 schrieb Roberto Ragusa:
> > On 5/22/24 16:33, Marius Schwarz wrote:
> >
> > > So, atm, the server has a sshd that says, that openssl is newer as
> > > the required openssl version. It does not start it
Am 24.05.24 um 12:01 schrieb Roberto Ragusa:
On 5/22/24 16:33, Marius Schwarz wrote:
So, atm, the server has a sshd that says, that openssl is newer as
the required openssl version. It does not start it nor can the
running sshd, that runs the upgrade connection, fork a new instance.
In other
On 5/22/24 16:33, Marius Schwarz wrote:
So, atm, the server has a sshd that says, that openssl is newer as the required
openssl version. It does not start it nor can the running sshd, that runs the
upgrade connection, fork a new instance. In other words: no login possible to
rescue or
Short summery:
we just talk about a small improvement.
It works like it is now, but risks can me minimized with small adaptions
to the package sort order in dnf while upgrading.
Am 23.05.24 um 06:14 schrieb Peter Boy:
I'm under the impression, there is a small misunderstanding here: The
> Am 23.05.2024 um 00:29 schrieb Marius Schwarz :
>
> Am 22.05.24 um 17:48 schrieb Alexander Sosedkin:
>> On Wed, May 22, 2024 at 4:34 PM Marius Schwarz
>> wrote:
>>
>>> Were you following the steps outlined in
>>> https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline ?
On 5/22/24 3:29 PM, Marius Schwarz wrote:
Am 22.05.24 um 17:48 schrieb Alexander Sosedkin:
On Wed, May 22, 2024 at 4:34 PM Marius Schwarz wrote:
Were you following the steps outlined in
https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline ?
I'm under the impression,
Am 22.05.24 um 17:48 schrieb Alexander Sosedkin:
On Wed, May 22, 2024 at 4:34 PM Marius Schwarz wrote:
Were you following the steps outlined in
https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline ?
I'm under the impression, there is a small misunderstanding here: The
On Wed, May 22, 2024 at 4:34 PM Marius Schwarz wrote:
> ATM I'm upgrading a remote server from F38 to F39 via SSH login.
>
> The bash runs a screen, so if ssh or the network dies, the upgrade can
> continue.
>
> I just noticed that even if it keeps running, it's useless because
> openssl und
Hi,
ATM I'm upgrading a remote server from F38 to F39 via SSH login.
The bash runs a screen, so if ssh or the network dies, the upgrade can
continue.
I just noticed that even if it keeps running, it's useless because
openssl und openssh do not get upgraded after another.
So, atm, the
13 matches
Mail list logo
