| View previous topic :: View next topic |
| Author |
Message |
mozingod
n00b
Joined: 15 Jun 2003
Posts: 64
Location: Ohio
|
 Posted: Wed Mar 03, 2004 11:15 pm Post subject: Idea to easily keep your systems up to date... |
 |
|
I've been toying with the idea of backups for our fast growing number of Gentoo servers. Here's my current idea that I plan on starting pretty soon:
1) A perl script on each machine running as a cron job once or twice a week. It'll do a sync to the local in-house server, then an emerge -up world. Chop apart the output and put each line in a database.
2) Have a PHP site that'll read the database, and allow you to view all needed updates on each machine. You can then click a check box next to each update and update the database reflecting that you want that package updated.
3) Another Perl script will run on the server as a cron job every few days or so. It'll check the database, and if it sees a package it put in there that the admin authorized for update, it goes ahead and updates that package and reports how it did to the database.
4) The PHP site will have a summary page that can show which machines finished a package upgrade since the page was last viewed with the results of the upgrade.
I'd like to integrate etc-update into this nice centralized update idea somehow, but am not sure right now. Maybe something will come to mind once I start digging into this.
Anyone have any ideas on what to change/add? Please let me know! I plan to make it as generalized as possible so I can release it for others. |
|
| Back to top |
|
 |
jordant
n00b
Joined: 31 May 2003
Posts: 68
Location: Vancouver, BC
|
| Posted: Thu Mar 04, 2004 12:29 am Post subject: Re: Idea to easily keep your systems up to date... |
|
|
| mozingod wrote: | | 3) Another Perl script will run on the server as a cron job every few days or so. It'll check the database, and if it sees a package it put in there that the admin authorized for update, it goes ahead and updates that package and reports how it did to the database. |
Maybe instead of having it poll the database every couple days - you could have it check the database right after you schedule things to be updated. Or at least, midnight the day of...
Hm... |
|
| Back to top |
|
|
mozingod
n00b
Joined: 15 Jun 2003
Posts: 64
Location: Ohio
|
| Posted: Thu Mar 04, 2004 2:25 am Post subject: Re: Idea to easily keep your systems up to date... |
|
|
| jordant wrote: | | Maybe instead of having it poll the database every couple days - you could have it check the database right after you schedule things to be updated. Or at least, midnight the day of... |
Perhaps I should clarify. The server being updated (lets say SERVER1), will run the scripts specified by 1 and 3 above. It will update the database with what it has to update once or twice a week, and will run another every friday night (least amount of load?) to read the database and update based on that.
My plan was to have the web/SQL server be on seperate machines than SERVER1, so I don't know how I could have the web server tell SERVER1 to update after the admin checks them on the website. |
|
| Back to top |
|
|
jordant
n00b
Joined: 31 May 2003
Posts: 68
Location: Vancouver, BC
|
| Posted: Thu Mar 04, 2004 3:25 am Post subject: Re: Idea to easily keep your systems up to date... |
|
|
| mozingod wrote: | | Perhaps I should clarify. The server being updated (lets say SERVER1), will run the scripts specified by 1 and 3 above. It will update the database with what it has to update once or twice a week, and will run another every friday night (least amount of load?) to read the database and update based on that. |
Yeah that sounds good...
| mozingod wrote: | | My plan was to have the web/SQL server be on seperate machines than SERVER1, so I don't know how I could have the web server tell SERVER1 to update after the admin checks them on the website. |
You could easily write a simple client/server app that PHP (or something similar) on the webserver notifies SERVER1 to perform updates - or to do anything for that matter.
Although I tend to agree that they should be done at time of least load - but it would be nice to be able to force them from a gui ordeal. |
|
| Back to top |
|
|
aaronjb
Tux's lil' helper
Joined: 25 May 2003
Posts: 106
Location: Berkshire, UK
|
| Posted: Thu Mar 04, 2004 10:21 am Post subject: |
|
|
Certainly sounds like a really good idea - though thinking around it I can see a few potential problems:
Security - that'll need looking at carefully, especially if you have an option to force the server to update there and then.
And the hardest part will be successfully managing the etc-update side of things - especially as a lot of the time, you need to interactively merge the config files in question..
A very good idea though - and would be very worthwile for those of us with multiple servers.
Good luck!
_________________
#my gentoo farm |
|
| Back to top |
|
|
mozingod
n00b
Joined: 15 Jun 2003
Posts: 64
Location: Ohio
|
| Posted: Thu Mar 04, 2004 1:37 pm Post subject: |
|
|
| aaronjb wrote: | | Security - that'll need looking at carefully, especially if you have an option to force the server to update there and then. |
Could you explain? I'd plan on the usual password protected PHP site, so only authorized users can go in and acknowledge updates. As far as writing to the database, you could use strong/random passwords so it wouldn't be easy to write random update confirmations, etc. I don't see why there'd be any hesitation in forcing the server to upgrade at a certain time...
| Quote: | | And the hardest part will be successfully managing the etc-update side of things - especially as a lot of the time, you need to interactively merge the config files in question.. |
Yes, I agree. There are a few different GUI based frontends in development for etc-update at this time, and all show a lot of promise, so a web based version couldn't be to horrendisly hard. Handling the menu system of etc-update and the update process wouldn't be the hard part, but getting the information on what to update to and from the servers from a centralized web box. Parhaps I can include this information in another cron job on the servers to be plugged into the database and viewed? Not to sure at this point. |
|
| Back to top |
|
|
aaronjb
Tux's lil' helper
Joined: 25 May 2003
Posts: 106
Location: Berkshire, UK
|
| Posted: Sat Mar 06, 2004 1:33 pm Post subject: |
|
|
| mozingod wrote: | | aaronjb wrote: | | Security - that'll need looking at carefully, especially if you have an option to force the server to update there and then. |
Could you explain? |
Well, when I said security I wasn't so much thinking about the wrong people gaining access to the interface and performing updates that weren't wanted - afterall, this is likely to be something controlled by network admins etc anyway.. But what I meant was more along the lines of making sure that any server side scripts can't have their functions perverted and used to do something else - for example, like wipe out a system by hacking through the PHP admin engine and inserting commands into the database to 'rm -rf /*' which then get executed on the target server.. Things like that 
| Quote: | | Yes, I agree. There are a few different GUI based frontends in development for etc-update at this time, and all show a lot of promise, so a web based version couldn't be to horrendisly hard. Handling the menu system of etc-update and the update process wouldn't be the hard part, but getting the information on what to update to and from the servers from a centralized web box. Parhaps I can include this information in another cron job on the servers to be plugged into the database and viewed? Not to sure at this point. |
I didn't realise there were GUI interfaces to etc-update in development, oops
I think it might be a good idea to try and avoid too much cron-managed stuff, afterall that limits the possibilities for 'here and now' updates.
What about - and this might be unfeasible depending on your target servers - running Apache on all the target servers, and having everything handled by intercommunication via php and/or perl CGI scripts between the servers? I do like the idea of using the database and cron to schedule package updates, but I think the config file updating might be better handled on a realtime basis..
Still, promising ideas
Aaron
_________________
#my gentoo farm |
|
| Back to top |
|
|
mozingod
n00b
Joined: 15 Jun 2003
Posts: 64
Location: Ohio
|
| Posted: Sat Mar 06, 2004 6:33 pm Post subject: |
|
|
Ahh, I see what you're getting at now. Well all that I planned on putting in the database was the package name to update, and a flag on wheter to update it or not. So the server would always be running "emerge <package name from database>". So even if someone were to get into the database or PHP script to input other stuff, they'd get "emerge rm -rf /", which wouldn't do any good.
I've been thinking about switching to a daemoned program instead of cron. Thus removing the need for cron, and allowing semi-real time updates and such (by specifing in a config file how often to check for updates from the database, etc). It should also allow an easier way to handle etc-update.
Anyone know if it's possible to run a Perl script as a daemon? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
