PDA

View Full Version : Automate patching process



shevary
11-Aug-2013, 11:22
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.

jmozdzen
13-Aug-2013, 12:50
Hi shevary,


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.

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 :)

Regards,
Jens

Stevo
13-Aug-2013, 17:57
jmozdzen sounds like they 'said':

> 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

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

jmozdzen
13-Aug-2013, 18:28
Hi Stevo,


jmozdzen sounds like they 'said':
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.

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

Stevo
13-Aug-2013, 23:04
jmozdzen sounds like they 'said':

> 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

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
13-Aug-2013, 23:43
Stevo sounds like they 'said':

> 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.

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

jmozdzen
14-Aug-2013, 09:46
Hi Stevo,


Stevo sounds like they 'said':

> 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.

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

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

Stevo
14-Aug-2013, 14:39
jmozdzen sounds like they 'said':

> 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

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

Stevo
14-Aug-2013, 15:08
jmozdzen sounds like they 'said':

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

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

jmozdzen
14-Aug-2013, 15:11
Hi Stevo,



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

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
14-Aug-2013, 15:21
Hi Stevo,


jmozdzen sounds like they 'said':

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

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

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


It is usually unnecessary to recreate the CA and server certificate. If you think your CA or server certificate are not functioning as expected, you may need to recreate them. This TID explains how.

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

jmozdzen
14-Aug-2013, 15:23
Stevo,

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


Please note: if the server certificate of the SMT system has expired (by default this happens after one year), you don't need to re-create the CA. Just create a new server certificate, export it as common server certificate and restart the smt service as described above. There is no need to make any changes to the clients either as they will automatically accept the new server certificate because they already trust the Root CA.

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

Stevo
14-Aug-2013, 15:31
jmozdzen sounds like they 'said':

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

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

jmozdzen
14-Aug-2013, 15:38
Hi Stevo,

great you got it running & thanks for reporting back!

Regards,
Jens

Stevo
14-Aug-2013, 17:26
jmozdzen sounds like they 'said':

>
> Hi Stevo,
>
> great you got it running & thanks for reporting back!
>
> Regards,
> Jens

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

Stevo
14-Aug-2013, 17:49
jmozdzen sounds like they 'said':

>
> Hi Stevo,
>
> great you got it running & thanks for reporting back!
>
> Regards,
> Jens

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

jmozdzen
14-Aug-2013, 18:02
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" ;)

Regards,
Jens

Stevo
14-Aug-2013, 18:26
jmozdzen sounds like they 'said':

> I'd put my bet on "a" ;)
>
> Regards,
> Jens

So my response to jmozdzen's comment is...

It was "b".......... Should have taken you up on that bet. <G>

--
Stevo

jmozdzen
14-Aug-2013, 19:56
jmozdzen sounds like they 'said':

>
> Hi Stevo,
>
> great you got it running & thanks for reporting back!
>
> Regards,
> Jens

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,

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

jmozdzen
14-Aug-2013, 19:58
Hi Stevo,


jmozdzen sounds like they 'said':
> I'd put my bet on "a" ;)
>
> Regards,
> Jens

So my response to jmozdzen's comment is...

It was "b".......... Should have taken you up on that bet. <G>

--
Stevo

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

Regards,
Jens

Stevo
14-Aug-2013, 21:16
jmozdzen sounds like they 'said':

>
> Stevo;15175 Wrote:
> > jmozdzen sounds like they 'said':
> >
> > >
> > > Hi Stevo,
> > >
> > > great you got it running & thanks for reporting back!
> > >
> > > Regards,
> > > Jens
> >
> > 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,
>
> 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

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.

--
Stevo

Stevo
14-Aug-2013, 21:17
jmozdzen sounds like they 'said':

> well, I then ow you a solution. Wait, you already got that, I'm off
> the hook :D
>
> Regards,
> Jens

So my response to jmozdzen's comment is...

I would take a beer. ;-)

--
Stevo

jmozdzen
14-Aug-2013, 22:32
Hi Stevo,


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

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

Stevo
15-Aug-2013, 19:16
jmozdzen sounds like they 'said':

> 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

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.

Thanks again!!

--
Stevo

shevary
17-Aug-2013, 10:36
Hi Jens,

I am glad Stevo fixed his issue.

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?

thx

jmozdzen
17-Aug-2013, 22:05
Hi shevary,


Hi Jens,

I am glad Stevo fixed his issue.

Going back to my questions can you used SMT for patching SLES and Opensue?

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 download patches to reportistory and manually add the patches to machine?

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?


For instance if I have a machine in DMZ, can I use SMT to download the patches and apply the patches manually?

thx

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...

Regards,
Jens

Stevo
19-Aug-2013, 22:25
shevary sounds like they 'said':

> I am glad Stevo fixed his issue.

So my response to shevary's comment is...

Sorry for hijacking this thread, was not my intent. :-)

--
Stevo