I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
First I have to determine that a particular server needs updates. I suppose a daily script that would run "yum check-updates' and emails me the results could work, but then I would only want the email IF there was something to update, at my limited use of this option does not show anything to trigger a notify on changes. Does anyone know of a script that would do this?
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done todate is to start vncserver and connect via vnc to then run yum. I can even drop the vnc connection and come back later to check results. I have considered running yum disconnected (? when you end a command with &) and log the results to a file that you check later. What are practical approaches to this? I only have a few servers here to manage.
On 02/25/2013 02:48 PM, Robert Moskowitz wrote:
I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
First I have to determine that a particular server needs updates. I suppose a daily script that would run "yum check-updates' and emails me the results could work, but then I would only want the email IF there was something to update, at my limited use of this option does not show anything to trigger a notify on changes. Does anyone know of a script that would do this?
A daily cronjob could call "yum check-update" and use the return code to decide if the output should be mailed or not. From the yum man-page for "check-update": "Implemented so you could know if your machine had any updates that needed to be applied without running it interactively. Returns exit value of 100 if there are packages available for an update. Also returns a list of the packages to be updated in list format. Returns 0 if no packages are available for update. Returns 1 if an error occurred. Running in verbose mode also shows obsoletes."
So redirect the output into a file and when the return code is 100 mail that file to the admin.
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done todate is to start vncserver and connect via vnc to then run yum. I can even drop the vnc connection and come back later to check results. I have considered running yum disconnected (? when you end a command with &) and log the results to a file that you check later. What are practical approaches to this? I only have a few servers here to manage.
Use "screen". That gives you a sort of virtual terminal (many in fact) that works just like a regular shell except that when your connection drops the session will just become detached. After you reconnect you can call "screen -R" to re-attache to that session and continue as if nothing happened. Scripts keep running in a detached session and the output will be there once you re-attach again just like with your VNC method.
Regards, Dennis
On 02/25/2013 09:03 AM, Dennis Jacobfeuerborn wrote:
On 02/25/2013 02:48 PM, Robert Moskowitz wrote: So redirect the output into a file and when the return code is 100 mail that file to the admin.
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done todate is to start vncserver and connect via vnc to then run yum. I can even drop the vnc connection and come back later to check results. I have considered running yum disconnected (? when you end a command with &) and log the results to a file that you check later. What are practical approaches to this? I only have a few servers here to manage.
Use "screen". That gives you a sort of virtual terminal (many in fact) that works just like a regular shell except that when your connection drops the session will just become detached. After you reconnect you can call "screen -R" to re-attache to that session and continue as if nothing happened. Scripts keep running in a detached session and the output will be there once you re-attach again just like with your VNC method.
Something I have never installed and obviously missed all the references to it. I do recall seeing it in some threads. Just installed it on one system and tested vis ssh from another. Very nice. Thought there would be something better out there. VNC has its place in the toolbox, but definitely too much for something like this. Yes I know about the discussions about NX being better than VNC. I actually run VNC over SSH. But I also run it over HIP which is a very interesting test of HIP and HIP mobility.
On 2/25/2013 9:03 AM, Dennis Jacobfeuerborn wrote:
On 02/25/2013 02:48 PM, Robert Moskowitz wrote:
I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
First I have to determine that a particular server needs updates. I suppose a daily script that would run "yum check-updates' and emails me the results could work, but then I would only want the email IF there was something to update, at my limited use of this option does not show anything to trigger a notify on changes. Does anyone know of a script that would do this?
A daily cronjob could call "yum check-update" and use the return code to decide if the output should be mailed or not. From the yum man-page for "check-update": "Implemented so you could know if your machine had any updates that needed to be applied without running it interactively. Returns exit value of 100 if there are packages available for an update. Also returns a list of the packages to be updated in list format. Returns 0 if no packages are available for update. Returns 1 if an error occurred. Running in verbose mode also shows obsoletes."
So redirect the output into a file and when the return code is 100 mail that file to the admin.
I also like to add the "download-only" plugin to yum so that when I do go back and do the updates, the files are waiting and I don't have to wait around for them to be downloaded.
run "yum install yum-downloadonly"
and the in your script run " /usr/bin/yum --downloadonly -y update"
Hal
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done todate is to start vncserver and connect via vnc to then run yum. I can even drop the vnc connection and come back later to check results. I have considered running yum disconnected (? when you end a command with &) and log the results to a file that you check later. What are practical approaches to this? I only have a few servers here to manage.
This is where "screen" would come in very handy...eliminates the need to start up vncserver, you can still drop the connection and then come back and reattach to the screen session and get the results.
Robert Moskowitz wrote:
I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
Yeah, prod servers are nasty that way. You always want to do test or dev or the backup first, and wait a bit. <snip>
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done
That sounds, to me, as though you have very serious communications issues that need to be solved, and yesterday. We've used ssh here, and at my previous two? three? contracts, for years, and almost *never* have an ssh connection break.
We've got about 150 servers and workstations here, and I do most of the updates, and all of it with yum over ssh, though I've had times when I just yum -y update &, and check the logs in the morning.
mark
On 02/25/2013 09:56 AM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
Yeah, prod servers are nasty that way. You always want to do test or dev or the backup first, and wait a bit.
<snip> > Then there is the actual update. I learned long ago NOT to run yum over > an SSH connection, as WHEN that connection breaks in the middle of an > update, you can have quite a problem to clean up. All I have done That sounds, to me, as though you have very serious communications issues that need to be solved, and yesterday. We've used ssh here, and at my previous two? three? contracts, for years, and almost *never* have an ssh connection break.
Oh, it has rarely happened. Typically when I was at a conference, using their wifi, to reach home to fix something. Though once or twice my system I was working from decided to go south and then of course there went its ssh connections. No once long ago when my firewall was a Centos (4?) system running shorewall, it happened that my notebook hung and recovery was a task and a half. Burned once and all that.
We've got about 150 servers and workstations here, and I do most of the updates, and all of it with yum over ssh, though I've had times when I just yum -y update &, and check the logs in the morning.
On Mon, Feb 25, 2013 at 9:08 AM, Robert Moskowitz rgm@htt-consult.com wrote:
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done
That sounds, to me, as though you have very serious communications issues that need to be solved, and yesterday. We've used ssh here, and at my previous two? three? contracts, for years, and almost *never* have an ssh connection break.
Oh, it has rarely happened. Typically when I was at a conference, using their wifi, to reach home to fix something. Though once or twice my system I was working from decided to go south and then of course there went its ssh connections. No once long ago when my firewall was a Centos (4?) system running shorewall, it happened that my notebook hung and recovery was a task and a half. Burned once and all that.
If you are going to baby-sit the actual updates, I recommend installing the yum-plugin-downloadonly package. Then before you manually connect to watch it run, you can script a stack of 'ssh target_host yum -y --downloadonly update' for all your targets. That will figure out what updates you need and download to the yum cache directory but not install them. Then when you log in and run 'yum update' you'll still see the list and have a chance to cancel, but the download step is instant since the rpms are already there.
Am 25.02.2013 15:56, schrieb m.roth@5-cent.us:
Robert Moskowitz wrote:
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done
That sounds, to me, as though you have very serious communications issues that need to be solved, and yesterday. We've used ssh here, and at my previous two? three? contracts, for years, and almost *never* have an ssh connection break.
It does happen. SSH is not as forgiving to network glitches as one would wish sometimes. A firewall that drops idle or long-running TCP connections, a DSL link doing its daily PPPoE disconnect at an inopportune moment, a VPN tunnel dropping, a hole in UMTS coverage, have all killed a SSH connection for me one time or another.
On Feb 25, 2013, at 3:34 PM, Tilman Schmidt t.schmidt@phoenixsoftware.de wrote:
Am 25.02.2013 15:56, schrieb m.roth@5-cent.us:
Robert Moskowitz wrote:
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done
That sounds, to me, as though you have very serious communications issues that need to be solved, and yesterday. We've used ssh here, and at my previous two? three? contracts, for years, and almost *never* have an ssh connection break.
It does happen. SSH is not as forgiving to network glitches as one would wish sometimes. A firewall that drops idle or long-running TCP connections, a DSL link doing its daily PPPoE disconnect at an inopportune moment, a VPN tunnel dropping, a hole in UMTS coverage, have all killed a SSH connection for me one time or another.
Same here. It happens sometimes.
KeepAlive yes - in the sshd config helps when things get flaky... not really to save you from the broken network, but to notice it sooner...
Nate
On Mon, Feb 25, 2013 at 4:34 PM, Tilman Schmidt t.schmidt@phoenixsoftware.de wrote:
That sounds, to me, as though you have very serious communications issues that need to be solved, and yesterday. We've used ssh here, and at my previous two? three? contracts, for years, and almost *never* have an ssh connection break.
It does happen. SSH is not as forgiving to network glitches as one would wish sometimes. A firewall that drops idle or long-running TCP connections, a DSL link doing its daily PPPoE disconnect at an inopportune moment, a VPN tunnel dropping, a hole in UMTS coverage, have all killed a SSH connection for me one time or another.
Yum is fairly forgiving about interruptions these days. Normally you can do a yum-complete-transaction to pick up where you left off, although I did have a problem with that once when I forgot and ran an update that included freenx in a freenx session.
On 02/25/2013 08:48 AM, Robert Moskowitz wrote:
I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
First I have to determine that a particular server needs updates. I suppose a daily script that would run "yum check-updates' and emails me the results could work, but then I would only want the email IF there was something to update, at my limited use of this option does not show anything to trigger a notify on changes. Does anyone know of a script that would do this?
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done todate is to start vncserver and connect via vnc to then run yum. I can even drop the vnc connection and come back later to check results. I have considered running yum disconnected (? when you end a command with &) and log the results to a file that you check later. What are practical approaches to this? I only have a few servers here to manage.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Pulp is a Red Hat sponsored python application that manages local repo mirrors (basically a light version of Spacewalk). It has a client app that you can use to communicate with the Pulp server and bind to specific repositories. You can view the package catalog on each consumer, and then can push updates out to consumers at will. It uses MongoDB as the backend database where it keeps track of the package metadata, and has a pretty useful REST API.
----- Original Message ----- | I have read a couple old threads here on updates for servers, and I | am | looking for some mechanics to getting the actual updates done. I | don't | want automatic updates; I want to control when and what gets updated. | | First I have to determine that a particular server needs updates. I | suppose a daily script that would run "yum check-updates' and emails | me | the results could work, but then I would only want the email IF there | was something to update, at my limited use of this option does not | show | anything to trigger a notify on changes. Does anyone know of a | script | that would do this? | | Then there is the actual update. I learned long ago NOT to run yum | over | an SSH connection, as WHEN that connection breaks in the middle of an | update, you can have quite a problem to clean up. All I have done | todate is to start vncserver and connect via vnc to then run yum. I | can | even drop the vnc connection and come back later to check results. I | have considered running yum disconnected (? when you end a command | with | &) and log the results to a file that you check later. What are | practical approaches to this? I only have a few servers here to | manage.
This is where you need something like Katello or Spacewalk. These are management systems which look after managing your infrastructure in such a way that you can view what servers are out of compliance and what patches are waiting to be applied.
I'm currently evaluating Katello as a long term solution to our Red Hat GNU/Linux management. I'd hazard to guess that you'll probably want to do the same too.
On Mon, Feb 25, 2013 at 11:41 AM, James A. Peltier jpeltier@sfu.ca wrote:
This is where you need something like Katello or Spacewalk. These are management systems which look after managing your infrastructure in such a way that you can view what servers are out of compliance and what patches are waiting to be applied.
I'm currently evaluating Katello as a long term solution to our Red Hat GNU/Linux management. I'd hazard to guess that you'll probably want to do the same too.
These seem like serious overkill for a small number of servers, especially ones where you don't run a lot of local or 3rd party apps and thus should never have a reason to need anything but moderately frequent 'yum -y update' runs. What kind of time and resources does it take to understand, set up, and manage one of these beasts?
On 02/25/2013 12:50 PM, Les Mikesell wrote:
On Mon, Feb 25, 2013 at 11:41 AM, James A. Peltier jpeltier@sfu.ca wrote:
This is where you need something like Katello or Spacewalk. These are management systems which look after managing your infrastructure in such a way that you can view what servers are out of compliance and what patches are waiting to be applied.
I'm currently evaluating Katello as a long term solution to our Red Hat GNU/Linux management. I'd hazard to guess that you'll probably want to do the same too.
These seem like serious overkill for a small number of servers, especially ones where you don't run a lot of local or 3rd party apps and thus should never have a reason to need anything but moderately frequent 'yum -y update' runs. What kind of time and resources does it take to understand, set up, and manage one of these beasts?
Let's see. I have 4 productions servers: DNS, web, mail, and samba; with samba locked up on a private net. Only DNS is current, the rest are work in progress. I just built my test DNS, which will make the rest easier. So MAYBE 8 boxes, with only 4 up 24/7. Not something to throw a server management system at. I do have a real job which I have to work on this afternoon and tonight.
On Mon, Feb 25, 2013 at 11:59 AM, Robert Moskowitz rgm@htt-consult.com wrote:
Let's see. I have 4 productions servers: DNS, web, mail, and samba; with samba locked up on a private net. Only DNS is current, the rest are work in progress. I just built my test DNS, which will make the rest easier. So MAYBE 8 boxes, with only 4 up 24/7. Not something to throw a server management system at. I do have a real job which I have to work on this afternoon and tonight.
DNS servers should be built with failover in mind. In the very unlikely event that an update would break something, as long as you haven't automated the same change across all of them, it shouldn't affect anything else.
On Mon, Feb 25, 2013 at 7:48 AM, Robert Moskowitz rgm@htt-consult.com wrote:
I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
Keep in mind that to _not_ install an update, you have to know more than the RH engineers about the code. I usually assume they had a good reason for going to the trouble of shipping it and that they would have to have a very, very good reason to ship anything that would break an existing API in an update. Of course it is always good policy to test the combination of things you run in production on a non-critical box first.
First I have to determine that a particular server needs updates. I suppose a daily script that would run "yum check-updates' and emails me the results could work, but then I would only want the email IF there was something to update, at my limited use of this option does not show anything to trigger a notify on changes. Does anyone know of a script that would do this?
How about just joining the centos-announce mail list?
On 02/25/2013 01:00 PM, Les Mikesell wrote:
On Mon, Feb 25, 2013 at 7:48 AM, Robert Moskowitz rgm@htt-consult.com wrote:
I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
Keep in mind that to _not_ install an update, you have to know more than the RH engineers about the code. I usually assume they had a good reason for going to the trouble of shipping it and that they would have to have a very, very good reason to ship anything that would break an existing API in an update. Of course it is always good policy to test the combination of things you run in production on a non-critical box first.
For example, an apache update MAY require that I first check what it will do to http.conf. First install it on a test server, check out what is new, then apply it. Or a firefox update, and I only run firefox anymore on the server when I am running in via vnc, and probably will never again (after setup) run firefox, so I will apply that update when I don't have something more to do. I see mysqld on my DNS server, but I have it off. Also cups is there, and I don't do printing. I have not uninstalled these, so if they get updates, I will apply them, but not when I am on the road. Now a bind or apache security update will get applied....
yes, I still tend to install desktop on my servers to get them configured, the set inittab to 3 and will rarely ever run desktop again.
First I have to determine that a particular server needs updates. I suppose a daily script that would run "yum check-updates' and emails me the results could work, but then I would only want the email IF there was something to update, at my limited use of this option does not show anything to trigger a notify on changes. Does anyone know of a script that would do this?
How about just joining the centos-announce mail list?
I am on it, and I do look at the announcements. Still which rpm is used on which server? What is critical and what is not?
On Mon, Feb 25, 2013 at 12:35 PM, Robert Moskowitz rgm@htt-consult.com wrote:
Keep in mind that to _not_ install an update, you have to know more than the RH engineers about the code. I usually assume they had a good reason for going to the trouble of shipping it and that they would have to have a very, very good reason to ship anything that would break an existing API in an update. Of course it is always good policy to test the combination of things you run in production on a non-critical box first.
For example, an apache update MAY require that I first check what it will do to http.conf.
I suppose it is possible - but I can't recall that ever happening. And I have some oddball httpd.confs. This is why we use 'enterprise' distributions. Updates are not supposed to break things.
First install it on a test server, check out what is new, then apply it. Or a firefox update, and I only run firefox anymore on the server when I am running in via vnc, and probably will never again (after setup) run firefox, so I will apply that update when I don't have something more to do. I see mysqld on my DNS server, but I have it off. Also cups is there, and I don't do printing. I have not uninstalled these, so if they get updates, I will apply them, but not when I am on the road. Now a bind or apache security update will get applied....
All reasonable thoughts, but you are getting to the point of spending more time figuring out if you need to do an update than you would to just run one and watch what it does. At the end of the run you are finished with that box and you know if it is important to do the others right away. If you do that on the test box you mentioned you'll also know if anything breaks.
yes, I still tend to install desktop on my servers to get them configured, the set inittab to 3 and will rarely ever run desktop again.
That will greatly increase the amount of updates you'll install over the life of the box. And you can't assume that a security update for something that isn't running is not needed - it might relate to ways to become root after some other exploit permits local access.
Robert Moskowitz wrote:
On 02/25/2013 01:00 PM, Les Mikesell wrote:
On Mon, Feb 25, 2013 at 7:48 AM, Robert Moskowitz rgm@htt-consult.com wrote:
I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
Keep in mind that to _not_ install an update, you have to know more than the RH engineers about the code. I usually assume they had a good reason for going to the trouble of shipping it and that they would have to have a very, very good reason to ship anything that would break an existing API in an update. Of course it is always good policy to test the combination of things you run in production on a non-critical box first.
<snip>
I am on it, and I do look at the announcements. Still which rpm is used on which server? What is critical and what is not?
AH! *Now* I get it. There's a security plugin for yum that you can install (see http://www.cyberciti.biz/faq/redhat-fedora-centos-linux-yum-installs-security-updates/), and you can have that do *just* those.
mark
Dne 25.2.2013 14:48, Robert Moskowitz napsal(a):
I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
First I have to determine that a particular server needs updates. I suppose a daily script that would run "yum check-updates' and emails me the results could work, but then I would only want the email IF there was something to update, at my limited use of this option does not show anything to trigger a notify on changes. Does anyone know of a script that would do this?
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done todate is to start vncserver and connect via vnc to then run yum. I can even drop the vnc connection and come back later to check results. I have considered running yum disconnected (? when you end a command with &) and log the results to a file that you check later. What are practical approaches to this? I only have a few servers here to manage.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi, We update all the boxes over ssh. Works fine. Those who are afraid of disconnections may always run it within tmux/screen session. As to managing the whole infra, the best tool for that is Spacewalk, but it might be too big for you. So, you can have nagios to check yum status on all the boxes. There is also a tool called apt-dater, see http://www.ibh.de/apt-dater/ Regardless the "APT" in the name it handles yum well. DH
On Tue, Feb 26, 2013 at 11:31 PM, David Hrbáč david-lists@hrbac.cz wrote:
Hi, We update all the boxes over ssh. Works fine. Those who are afraid of disconnections may always run it within tmux/screen session. As to managing the whole infra, the best tool for that is Spacewalk, but it might be too big for you. So, you can have nagios to check yum status on all the boxes. There is also a tool called apt-dater, see http://www.ibh.de/apt-dater/ Regardless the "APT" in the name it handles yum well.
I don't remember if I've tried this or not, but it should work to simply: nohup yum -y update & and disconnect (or not....). Nohup will redirect stdout and stderr to a file named nohup.out that you can check later if you haven't already redirected elsewhere and disconnects the command from the terminal session so it won't be killed if you log out or disconnect.
Les Mikesell wrote:
On Tue, Feb 26, 2013 at 11:31 PM, David Hrbáč david-lists@hrbac.cz wrote:
Hi, We update all the boxes over ssh. Works fine. Those who are afraid of disconnections may always run it within tmux/screen session. As to managing the whole infra, the best tool for that is Spacewalk, but it might be too big for you. So, you can have nagios to check yum status on all the boxes. There is also a tool called apt-dater, see http://www.ibh.de/apt-dater/ Regardless the "APT" in the name it handles yum well.
I don't remember if I've tried this or not, but it should work to simply: nohup yum -y update & and disconnect (or not....). Nohup will redirect stdout and stderr to a file named nohup.out that you can check later if you haven't already redirected elsewhere and disconnects the command from the terminal session so it won't be killed if you log out or disconnect.
I can guarantee that I've started a yum update late in the day, and for some reason the network was *very* slow, and there were a lot of updates, and I just bg'd it and logged out, and it was finished later that evening.
mark
On Wed, Feb 27, 2013 at 12:31 AM, David Hrbáč david-lists@hrbac.cz wrote:
Dne 25.2.2013 14:48, Robert Moskowitz napsal(a):
I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
First I have to determine that a particular server needs updates. I suppose a daily script that would run "yum check-updates' and emails me the results could work, but then I would only want the email IF there was something to update, at my limited use of this option does not show anything to trigger a notify on changes. Does anyone know of a script that would do this?
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done todate is to start vncserver and connect via vnc to then run yum. I can even drop the vnc connection and come back later to check results. I have considered running yum disconnected (? when you end a command with &) and log the results to a file that you check later. What are practical approaches to this? I only have a few servers here to manage.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi, We update all the boxes over ssh. Works fine. Those who are afraid of disconnections may always run it within tmux/screen session. As to
+1 for screen For those that want/need to be safe, screen is the best way.
managing the whole infra, the best tool for that is Spacewalk, but it might be too big for you. So, you can have nagios to check yum status on all the boxes. There is also a tool called apt-dater, see http://www.ibh.de/apt-dater/ Regardless the "APT" in the name it handles yum well. DH _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 02/25/2013 07:48 AM, Robert Moskowitz wrote:
I have read a couple old threads here on updates for servers, and I am looking for some mechanics to getting the actual updates done. I don't want automatic updates; I want to control when and what gets updated.
First I have to determine that a particular server needs updates. I suppose a daily script that would run "yum check-updates' and emails me the results could work, but then I would only want the email IF there was something to update, at my limited use of this option does not show anything to trigger a notify on changes. Does anyone know of a script that would do this?
Then there is the actual update. I learned long ago NOT to run yum over an SSH connection, as WHEN that connection breaks in the middle of an update, you can have quite a problem to clean up. All I have done todate is to start vncserver and connect via vnc to then run yum. I can even drop the vnc connection and come back later to check results. I have considered running yum disconnected (? when you end a command with &) and log the results to a file that you check later. What are practical approaches to this? I only have a few servers here to manage.
Using screen on the remote server while on ssh is a very safe way to update remote servers.
Screen will make your session persistent (it goes into detached mode if the connection drops, but still keeps running). You can detach from screen session (ctrl-a ctrl-d) then come back later and reconnect with screen -x.
I literally manage/update hundreds of remote servers weekly using screen. I hardly every have enough X packages running on any of the servers I manage to run vnc.
-
David Hrbáč -
Dennis Jacobfeuerborn -
Harold Pritchett -
James A. Peltier -
Johnny Hughes -
Les Mikesell -
m.roth＠5-cent.us -
Mike Burger -
Nathan Duehr -
Phil Gardner -
Robert Moskowitz -
SilverTip257 -
Tilman Schmidt