SMT & New Patches

SUSE Linux Enterprise Server SLES Updates
1

Please correct me if I am posting to the wrong area, but this seems to be where most of the SMT questions are asked.

I don’t fully understand something regarding the repositories. I understand that you have to mirror the repository, put it into a testing repo, then a production repo for all of your servers to be able to download the updates. What I don’t understand is how to I update the production repository when a new patch it releases for the repo I have already mirrored?

From reading the manual, I understand that the testing environment is automatically updated; but how do I update the production environment with this new patch also?

2

[QUOTE=peter1292;27557]Please correct me if I am posting to the wrong area, but this seems to be where most of the SMT questions are asked.

I don’t fully understand something regarding the repositories. I understand that you have to mirror the repository, put it into a testing repo, then a production repo for all of your servers to be able to download the updates. What I don’t understand is how to I update the production repository when a new patch it releases for the repo I have already mirrored?

From reading the manual, I understand that the testing environment is automatically updated; but how do I update the production environment with this new patch also?[/QUOTE]

As far as I know you don’t have to create testing and production repos. It’s a good idea to and point a subset of machines at testing and everything else at production, but you don’t have to.

I update production repos with

$ smt-staging createrepo  name_of_repo --production

I don’t have the GUI installed, but the method of doing it in YaST seems to be described at
https://www.suse.com/documentation/smt11/book_yep/data/smt_yast_staging_stage.html

I update testing repos with

$ smt-staging createrepo  name_of_repo --testing

As far as I know they don’t get updated automatically.

I have a cronjob that runs smt-mirror every night and then calls smt-staging to create the testing repos.

3

[QUOTE=mikewillis;27577]As far as I know you don’t have to create testing and production repos. It’s a good idea to and point a subset of machines at testing and everything else at production, but you don’t have to.

I update production repos with

$ smt-staging createrepo  name_of_repo --production

I don’t have the GUI installed, but the method of doing it in YaST seems to be described at
https://www.suse.com/documentation/smt11/book_yep/data/smt_yast_staging_stage.html

I update testing repos with

$ smt-staging createrepo  name_of_repo --testing

As far as I know they don’t get updated automatically.

I have a cronjob that runs smt-mirror every night and then calls smt-staging to create the testing repos.[/QUOTE]

Thanks Mike!
I couldn’t get any of the servers to update without putting them into testing and then production repositories. The manual says you don’t have to, but I cannot get it to work without.

The CLI is also how I administrate the SMT servers, so it is great to have someone else who can help me with the information as the manual can be lacking for CLI…

With regards to the cron job, that is a fantastic idea! I may have to add that into ours :slight_smile:

4

[QUOTE=peter1292;27578]Thanks Mike!
I couldn’t get any of the servers to update without putting them into testing and then production repositories. The manual says you don’t have to, but I cannot get it to work without.

The CLI is also how I administrate the SMT servers, so it is great to have someone else who can help me with the information as the manual can be lacking for CLI…
[/QUOTE]
I don’t do that much with SMT really. I set it up, it runs. I think the only interactions I’ve done with it this year is to switch it to using suse.com instead of novell.com and enabling mirroring the SLE 12 repos.

[QUOTE=peter1292;27578]
With regards to the cron job, that is a fantastic idea! I may have to add that into ours :)[/QUOTE]

FWIW, below are the scripts I use. smtjobs_getupdates runs nightly. smtjobs_makeproductionrepos runs weekly, unless I intervene for some reason. I don’t offer any guarantee of fitness for purpose, but they were last modified about four years ago so they can’t be too bad. :wink:

[CODE]foo:~ # cat /usr/local/sbin/smtjobs_getupdates
#!/bin/bash

echo “Starting at $(date)”;

source /usr/local/etc/smtjobs_functions;

smt-sync;

smt-mirror;

cmd_on_all_repos “smt staging allow --all”;

cmd_on_all_repos “smt-staging status”;

cmd_on_all_repos “smt-staging createrepo” “–testing”;

echo “Finished at $(date)”;

foo:~ # cat /usr/local/sbin/smtjobs_makeproductionrepos
#!/bin/bash

echo “Starting at $(date)”;

source /usr/local/etc/smtjobs_functions;

cmd_on_all_repos “smt-staging createrepo” “–production”;

echo “Finished at $(date)”;
foo:~ # cat /usr/local/etc/smtjobs_functions

runs command passed as $1 on all enabled repos except -Pool and -Core nvidia

ones since you can’t run the staging commands on those

function cmd_on_all_repos () {
smt-repos --only-enabled | grep SLE | grep -v – -Pool | grep -v – -Core | grep -vi nvidia | cut -d ‘|’ -f 5,6 --output-delimiter=’ ’ | sed ‘s/ \(sle\)/ \1/’ | while read repo;do
echo “Running $1 $2 on $repo …”;
echo -e "

";
done
echo -e "

=====================================================

";
}
foo:~ #[/CODE]