great you got it running & thanks for reporting back!
Regards,
Jens[/color]
So my response to jmozdzen’s comment is…
Of course another oddity shows up. Picked a server, installed
latest patches (including July 2013 OES Maint patch), rebooted, no
updates available.
Looking on the SMT box, this server still shows a critical status
with updates needed…sigh
–
Stevo[/color]
Hi Stevo,
with “installed latest updates” you mean installing them manually,
right? Invoking “zypper up” (or alike) does nothing to your SMT
status, you’d need to invoke “smtclient” manually after the update,
too. Of course, the cron’ly invocation will “heal” you client’s
status, too.
Think of SMT as providing a local repository (periodically syncing
that with the Novell master repository) and a client component that
acts as a wrapper to local packet management and reports back the
resulting patch status to the SMT server.
Regards,
Jens[/color]
So my response to jmozdzen’s comment is…
You mean invoke smt-agent manually after an update? I did that on the
first server I updated a half dozen times, it still always showed up in
a critical state.
[QUOTE=Stevo;15182]
You mean invoke smt-agent manually after an update? I did that on the
first server I updated a half dozen times, it still always showed up in
a critical state.
–
Stevo[/QUOTE]
then my memory didn’t serve me right. Nevertheless, give it a few hours to a day (maybe some update interval at the server side blocks updating the status), if it still reports “critical” without new updates being required, I’ll help looking into it more closely.
then my memory didn’t serve me right. Nevertheless, give it a few
hours to a day (maybe some update interval at the server side blocks
updating the status), if it still reports “critical” without new
updates being required, I’ll help looking into it more closely.
Regards,
Jens[/color]
So my response to jmozdzen’s comment is…
So I guess I was just too impatient. Updated a different server this
morning, couple hours later it shows as up to date on the SMT box.
Going back to my questions can you used SMT for patching SLES and Opensue?
Can you download patches to reportistory and manually add the patches to machine?
For instance if I have a machine in DMZ, can I use SMT to download the patches and apply the patches manually?
Going back to my questions can you used SMT for patching SLES and Opensue?[/QUOTE]
Hm, at least we are not using SMT for this - although we have our openSUSE repositories shadowed to the same server machine SMT is running on. The repository list on the openSUSE machines is set up to use the local repositories via NFS or FTP (depending on the network connection) and updates are applied using standard openSUSE mechanisms.
Can you elaborate on what you’re trying to achieve? Do you want to add your own patches to the repos? Or are you after deciding which (official) patches are distributed to the servers?
[QUOTE=shevary;15246]For instance if I have a machine in DMZ, can I use SMT to download the patches and apply the patches manually?
thx[/QUOTE]
Are you talking about setting up a SMT server in the DMZ to shadow the offical patches to your DMZ, and feeding those to you machines manually? That will work, all you need to do is to disable the cron job for the SMT client and invoke “zypper” on demand on the client machine. In case of a client view behind your question: SMT won’t download the patches to the (SMT client) machine, it rather invokes “zypper” to pull the patches and updates the resulting status at the SMT server. So if you’re looking at the client side of things, then no: SMT won’t download, you’d rather have to invoke “zypper” manually, which then will download from your SMT server.
I may have misunderstood you in some parts, then please let me know so I can try to give more matching answers…
