We are using SLES 11Sp2 servers and would like to move them to latest patches and version.
There are about 10 servers, which need to be patched.
Since, we have never done a patching on all of the servers at the same, would like to have some insight and directions that we would need to keep in mind in this case.
As a starting point we have configured a SMT server to create a local repository for our servers.
Could you please provide some guildelines for the process of patching and making this activity a smooth ones?
Since, we have never done a patching on all of the servers at the same, would like to have some insight and directions that we would need to keep in mind in this case.
have you seen https://www.suse.com/support/kb/doc.php?id=7012368 ? And please watch out for services running on those servers that may be required during updates - i.e. DNS servers, gateway functions or alike… you should update all servers at the same time then
A full distro update can put some load on the network and the SMT server, this need cause harm but is something to keep in mind, too.
As a starting point we have configured a SMT server to create a local repository for our servers.
I’d update the SMT server first. Once that one is at the current level, update the other machines.
Since, we have never done a patching on all of the servers at the same, would like to have some insight and directions that we would need to keep in mind in this case.
have you seen https://www.suse.com/support/kb/doc.php?id=7012368 ? And please watch out for services running on those servers that may be required during updates - i.e. DNS servers, gateway functions or alike… you should update all servers at the same time then
A full distro update can put some load on the network and the SMT server, this need cause harm but is something to keep in mind, too.
As a starting point we have configured a SMT server to create a local repository for our servers.
I’d update the SMT server first. Once that one is at the current level, update the other machines.
With regards,
Jens[/QUOTE]
Thanks for the suggestions Jens
I was under the impression that I can go ahead and update all the servers first and do the SMT last, but, will change the plan accordingly.
Since, we have never done a patching on all of the servers at the same, would like to have some insight and directions that we would need to keep in mind in this case.
have you seen https://www.suse.com/support/kb/doc.php?id=7012368 ? And please watch out for services running on those servers that may be required during updates - i.e. DNS servers, gateway functions or alike… you should update all servers at the same time then
A full distro update can put some load on the network and the SMT server, this need cause harm but is something to keep in mind, too.
As a starting point we have configured a SMT server to create a local repository for our servers.
I’d update the SMT server first. Once that one is at the current level, update the other machines.
With regards,
Jens[/QUOTE]
I went the further configuration and for test registered one server with SMT, now the server is being listed in the clients list.
But, when I go to the new registered server and check online updates, it does not show any patches or updates available…
But, when I go to the new registered server and check online updates, it does not show any patches or updates available.
I assume that “zypper lr -d” on the client machine does indeed show the repositories from the SMT server - so then, did your SMT server ever fetch the update channels to it’s local mirror repositories? Does “smt-catalogs -o” report that you have enabled mirroring for the products of your client systems? If you run “smt-mirror” manually, does it fetch updates to the mirror repositories required for your client systems?
But, when I go to the new registered server and check online updates, it does not show any patches or updates available.
I assume that “zypper lr -d” on the client machine does indeed show the repositories from the SMT server - so then, did your SMT server ever fetch the update channels to it’s local mirror repositories? Does “smt-catalogs -o” report that you have enabled mirroring for the products of your client systems? If you run “smt-mirror” manually, does it fetch updates to the mirror repositories required for your client systems?
With regards,
Jens[/QUOTE]
Ran the smt-catalogs -o, and it showed me only one repository as below:
[FONT=Courier New]
.-----------------------------------------------------------------------------------------------------------------------------.
| Mirror? | ID | Type | Name | Target | Description | Can be Mirrored | Staging |
±--------±—±-----±-------------------±--------------±-------------------------------------±----------------±--------+
| Yes | 1 | nu | SLES11-SP2-Updates | sle-11-x86_64 | SLES11-SP2-Updates for sle-11-x86_64 | Yes | Yes |
‘---------±—±-----±-------------------±--------------±-------------------------------------±----------------±--------’
[/FONT]
Does this mean that I would have to go each of these repos and enable mirroring for them?
sorry for the late reply - times are rather busy at the moment.
[QUOTE=ddgaikwad;22435]Hi Jens,
Ran the smt-catalogs -o, and it showed me only one repository as below:
[FONT=Courier New]
.-----------------------------------------------------------------------------------------------------------------------------.
| Mirror? | ID | Type | Name | Target | Description | Can be Mirrored | Staging |
±--------±—±-----±-------------------±--------------±-------------------------------------±----------------±--------+
| Yes | 1 | nu | SLES11-SP2-Updates | sle-11-x86_64 | SLES11-SP2-Updates for sle-11-x86_64 | Yes | Yes |
‘---------±—±-----±-------------------±--------------±-------------------------------------±----------------±--------’
[/FONT]
Does this mean that I would have to go each of these repos and enable mirroring for them?
Thank you,
-ddgaikwad[/QUOTE]
yes, you’ll have to enable mirroring for those repositories that are needed in your environment. It would be nice if SMT did this automatically when registering a client that needs a currently unmirrored repos (and had an option to enable/disable such a feature by SMT admin decision)… maybe it has, but I haven’t looked deep enough to find it
sorry for the late reply - times are rather busy at the moment.
yes, you’ll have to enable mirroring for those repositories that are needed in your environment. It would be nice if SMT did this automatically when registering a client that needs a currently unmirrored repos (and had an option to enable/disable such a feature by SMT admin decision)… maybe it has, but I haven’t looked deep enough to find it
Regards,
Jens[/QUOTE]
Thanks, will start working on gathering the required repos for all these server which would be connecting to this SMT server.
