Automate patching process

Hi Guys,

I have around 10 SLES11 VMware versions and I want to patch these VMs, I use Microsoft SCCM to patch Windows server, I am looking for the tool to automate the patching process, at the moment I am using the Yast to patch these servers and I came across the Novell SUSE Subscription Management Tool (SMT), and I have the following questions:

  1. If you are using this SMT can you please share your experience?
  2. Can you run a compliance report for any security issues?
  3. Can you a run a report to see what server is missing updates?
  4. How do you push the updates? Do you have controller on what you want to include in the update?
  5. Is this tool comes with GUI interface?

Thanks in Advance.

Hi shevary,

[QUOTE=shevary;15084]Hi Guys,

I have around 10 SLES11 VMware versions and I want to patch these VMs, I use Microsoft SCCM to patch Windows server, I am looking for the tool to automate the patching process, at the moment I am using the Yast to patch these servers and I came across the Novell SUSE Subscription Management Tool (SMT), and I have the following questions:

  1. If you are using this SMT can you please share your experience?
  2. Can you run a compliance report for any security issues?
  3. Can you a run a report to see what server is missing updates?
  4. How do you push the updates? Do you have controller on what you want to include in the update?
  5. Is this tool comes with GUI interface?

Thanks in Advance.[/QUOTE]

we’re running SMT to support our SLES10/11 development VMs with the latest patches.

If you are using this SMT can you please share your experience?

We’re not the most sophisticated users when it comes to SMT, just distributing patches as they come. That works flawlessly and gives us both the support (information) we need and the independence from Internet-based servers. Our SMT machine is the installation source for openSuSE installs, too (but not via SMT)

Can you run a compliance report for any security issues?

You can query SMT’s database for the patch status - “critical” says there are security-related patches pending, “unknown” are hosts that are not running the client tool (but were registered against the SMT server via YaST), “up-to-date” is obvious.

:~ # smt-client .-----------------------------------------------------------------------------------------. | GUID | Hostname | Patch Status | Patch Status Date | +----------------------------------+-----------------+--------------+---------------------+ | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | host1 | Unknown | | | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | host2 | Critical | 2013-08-13 12:48:28 | | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | host3 | Up-to-date | 2013-08-13 12:22:38 | '----------------------------------+-----------------+--------------+---------------------'

When you run “smt-client -v”, the information is expanded to give you each the number of missed security patches, patch management patches, recommended patches and optional patches, as well as the time stamp of the last contact (SMT client on remote host contacting SMT server, whether retrieving patches or just looking for updates).

Can you a run a report to see what server is missing updates?

See above

How do you push the updates? Do you have controller on what you want to include in the update?

While I haven’t done so myself, AFAIK you can set up separate repositories, i.e. what’s coming from Novell’s server to your SMT vs. what you want your servers to see. It’s no software distribution tool, though: I’ve not seen means to push individual packages to individual servers.

Is this tool comes with GUI interface?

You’re not forced to use them, no - there are CLI tools, too. The GUI is provided by SMT’s YaST integration.

Hope this helps - if you need more details, just ask :slight_smile:

Regards,
Jens

jmozdzen sounds like they ‘said’:
[color=blue]

When you run “smt-client -v”, the information is expanded to give you
each the number of missed security patches, patch management patches,
recommended patches and optional patches, as well as the time stamp of
the last contact (SMT client on remote host contacting SMT server,
whether retrieving patches or just looking for updates).

Regards,
Jens[/color]

So my response to jmozdzen’s comment is…

I’ve been running an SMT box here for a couple years now, which is now
sles11sp2.

If I run the smt-client -v command on it, all my servers show as
unknown for all updates. Any suggestions as to what I can do to get
these to show properly? We are up to date aside from the latest batch
of patches that came out last week when I was on vacation.


Stevo

Hi Stevo,

[QUOTE=Stevo;15139]jmozdzen sounds like they ‘said’:[COLOR=blue]
[/COLOR]I’ve been running an SMT box here for a couple years now, which is now
sles11sp2.

If I run the smt-client -v command on it, all my servers show as
unknown for all updates. Any suggestions as to what I can do to get
these to show properly? We are up to date aside from the latest batch
of patches that came out last week when I was on vacation.[/QUOTE]

would you mind checking and sharing a sample line of the “smt-client -v” output and the related tail of /var/log/smtclient.log from the corresponding client system? The GUID named in the SMT output must match the username entry in /etc/zypp/credentials.d/NCCcredentials of the client system, so please verify this as well.

Regards,
Jens

jmozdzen sounds like they ‘said’:
[color=blue]

would you mind checking and sharing a sample line of the “smt-client
-v” output and the related tail of /var/log/smtclient.log from the
corresponding client system? The GUID named in the SMT output must
match the username entry in /etc/zypp/credentials.d/NCCcredentials of
the client system, so please verify this as well.

Regards,
Jens[/color]

So my response to jmozdzen’s comment is…

I got to thinking and I don’t have the SMT client installed on my
clients. Last time I tried putting the client agent on any of my
machines, I recall it wreaked havoc, causing that machine to not
update, etc, etc.


Stevo

Stevo sounds like they ‘said’:
[color=blue]

So my response to jmozdzen’s comment is…

I got to thinking and I don’t have the SMT client installed on my
clients. Last time I tried putting the client agent on any of my
machines, I recall it wreaked havoc, causing that machine to not
update, etc, etc.[/color]

So my response to Stevo’s comment is…

So I tried to install the SMT client rpm from the iso I downloaded it.
When I try to install it, it updates, but says the client is already
installed. I don’t have an smt-client log in /var/log however. Could
the log be somewhere else on sles11sp2?


Stevo

Hi Stevo,

[QUOTE=Stevo;15146]Stevo sounds like they ‘said’:
[COLOR=blue]

So my response to jmozdzen’s comment is…

I got to thinking and I don’t have the SMT client installed on my
clients. Last time I tried putting the client agent on any of my
machines, I recall it wreaked havoc, causing that machine to not
update, etc, etc.[/COLOR]

So my response to Stevo’s comment is…

So I tried to install the SMT client rpm from the iso I downloaded it.
When I try to install it, it updates, but says the client is already
installed. I don’t have an smt-client log in /var/log however. Could
the log be somewhere else on sles11sp2?


Stevo[/QUOTE]

well, it could be somewhere else, but with a clean install (no configuration modified), I doubt it.

jmozdzen@sles11sp2:~> cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 2 jmozdzen@sles11sp2:~> l /var/log/smtclient.log -rw------- 1 root root 813097 14. Aug 09:22 /var/log/smtclient.log jmozdzen@sles11sp2:~>

It might be the client was never run - have you tried invoking it manually and then looked for the log file?

Regards,
Jens

jmozdzen sounds like they ‘said’:
[color=blue]

well, it could be somewhere else, but with a clean install (no
configuration modified), I doubt it.

Code:

jmozdzen@sles11sp2:~> cat /etc/SuSE-release

SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
jmozdzen@sles11sp2:~> l /var/log/smtclient.log
-rw------- 1 root root 813097 14. Aug 09:22 /var/log/smtclient.log
jmozdzen@sles11sp2:~>

It might be the client was never run - have you tried invoking it
manually and then looked for the log file?

Regards,
Jens[/color]

So my response to jmozdzen’s comment is…

So how would one go about launching the client manually? I haven’t
seen anything along those lines in any of the docs I’ve read.


Stevo

Hi Stevo,

[QUOTE=Stevo;15163]
So how would one go about launching the client manually? I haven’t
seen anything along those lines in any of the docs I’ve read.


Stevo[/QUOTE]

Short version:

/usr/sbin/smt-agent

Long version:

Looking at the package contents via “rpm -ql xmt-client”, a file “/etc/cron.d/novell.com-smt-client” catches the eye: Obviously a file that will control client invocation via cron. Looking at that file you’ll see

22 */3 * * * root /usr/sbin/smt-agent

which according to cron’s manual page, will invoke the command “/usr/sbin/smt-agent” in the context of the user “root” every 3 hours, 22 minutes after the full hour.

Which, by the way, may be one (of many possible) reason(s) why your client was never run (if that actually proves to be the case): Do you have the cron service installed and activated?

Regards,
Jens

jmozdzen sounds like they ‘said’:
[color=blue]

It might be the client was never run - have you tried invoking it
manually and then looked for the log file?

Regards,
Jens[/color]

So my response to jmozdzen’s comment is…

Ok, figured out how to launch the client, but when I do, I get an error
(certificate verify failed) error.

Do we need to use our purchased cert in this setup to get this to work?
If so, how does one go about changing the cert for SMT?


Stevo

Hi Stevo,

[QUOTE=Stevo;15167]jmozdzen sounds like they ‘said’:
[COLOR=blue]

It might be the client was never run - have you tried invoking it
manually and then looked for the log file?

Regards,
Jens[/COLOR]

So my response to jmozdzen’s comment is…

Ok, figured out how to launch the client, but when I do, I get an error
(certificate verify failed) error.

Do we need to use our purchased cert in this setup to get this to work?
If so, how does one go about changing the cert for SMT?


Stevo[/QUOTE]

Throwing that question at a search engine (ok, I actually did abbreviate it a bit to “sles smt certificate”), it returned a pointer to the following support article:

http://www.novell.com/support/kb/doc.php?id=7006024

The certificate should match the SMT server (ok, more preceisely, the CN part of the DN must match the DNS name the clients use to access the SMT server), so “to use [your] purchased cert” might not be a good idea, assuming that the SMT server isn’t running on the server the certificate was created for.

Regards,
Jens

Stevo,

I forgot to explicitly point out the statement at the end of that article:

But as all your clients are displayed as if they have never connected before, I cannot tell if the server-side setup was ever completed successfully.

With regards,
Jens

jmozdzen sounds like they ‘said’:
[color=blue]

It might be the client was never run - have you tried invoking it
manually and then looked for the log file?

Regards,
Jens[/color]

So my response to jmozdzen’s comment is…

Ok, got it! Following tid 7006024, got a cert set up, agent started on
a machine I was trying it on.

Thanks for your help!


Stevo

Hi Stevo,

great you got it running & thanks for reporting back!

Regards,
Jens

jmozdzen sounds like they ‘said’:
[color=blue]

Hi Stevo,

great you got it running & thanks for reporting back!

Regards,
Jens[/color]

So my response to jmozdzen’s comment is…

I am having issues with one box. Did the same steps as all the others,
launch the agent, but it still shows unknown. Looking at the
/var/log/smtclient.log file, I see:

2013-08-14 09:50:54: (72) job 72 message: Refreshing the repositories
and services failed. Patch status can not be computed.

Suggestions?


Stevo

jmozdzen sounds like they ‘said’:
[color=blue]

Hi Stevo,

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

Hi Stevo,

I am having issues with one box. Did the same steps as all the others,
launch the agent, but it still shows unknown.

Suggestions?

a - verify that the system id is different from other systems (might have been a cloned machine). If it uses someone else’s id, remove the credentials file and re-register
b - if the client id is unique, remove the client from the SMT (“smt-delete-registration”) and re-register

I’d put my bet on “a” :wink:

Regards,
Jens

jmozdzen sounds like they ‘said’:
[color=blue]

I’d put my bet on “a” :wink:

Regards,
Jens[/color]

So my response to jmozdzen’s comment is…

It was “b”… Should have taken you up on that bet.


Stevo

[QUOTE=Stevo;15175]jmozdzen sounds like they ‘said’:
[COLOR=blue]

Hi Stevo,

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[/QUOTE]

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

Hi Stevo,

[QUOTE=Stevo;15177]jmozdzen sounds like they ‘said’:[COLOR=blue]

I’d put my bet on “a” :wink:

Regards,
Jens[/COLOR]

So my response to jmozdzen’s comment is…

It was “b”… Should have taken you up on that bet.


Stevo[/QUOTE]

well, I then ow you a solution. Wait, you already got that, I’m off the hook :smiley:

Regards,
Jens