Author Topic: Request Clarification of Update Default Action  (Read 4498 times)

Sam Graf

  • Guest
Re: Request Clarification of Update Default Action
« Reply #15 on: May 09, 2009, 01:33:21 pm »
When conducting troubleshooting, having the most up to date versions of the software installed is a frequent recommendation.  Currently this is done in two ways:
  • Wait for eBox to reach the appointed time to download (and possibly install them). This may not be helpful in achieving an immediate diagnosis.
  • Force an immediate download of pending updates.
Ah, yes. I get that. In fact, fixing a problem with an update is one of those infrequent "special cases" I was mentioning earlier, and it would be nice not to have to ssh in on top of my existing browser session if all I need to do is give eBox's software update machinery a little nudge.

Presently eBox runs its updating task at midnight each day.  This takes no account of whatever else may be happening in the machine or LAN.  If this is updating task a fixed timing event, it is possible that the only solution available to the system administrator is to attempt to reschedule all the other scheduled tasks to accommodate eBox.

The ability to modify the eBox scheduled tasks via it web-GUI seems desirable and will again enhance its user friendliness.
Sure. I guess I still wonder what real (as opposed to eBox wannabe types like me  ;D ) Ubuntu server admins do in this regard. Maybe they do make it a practice to tinker with the schedule. Or maybe the server comes first and they just do everything else to suit. In other words, in all of these types of configuration issues I would expect eBox to attempt to reflect and simplify real world Ubuntu admin behavior and not to attempt anticipating a lot of what ifs, and in this case (well, in most every case), I don't know what the real world behavior might be. I myself have not yet felt an itch to alter Ubuntu server's default behavior here, but maybe I'm just being lazy about the whole thing. I dunno. And I don't want to belabor the point since I'm just undecided about the whole thing and talking more from my ignorance than anything else. :-\

SamK

  • Zen Samurai
  • ****
  • Posts: 283
  • Karma: +3/-0
    • View Profile
Re: Request Clarification of Update Default Action
« Reply #16 on: May 09, 2009, 02:16:27 pm »
I guess I still wonder what real (as opposed to eBox wannabe types like me  ;D ) Ubuntu server admins do in this regard. Maybe they do make it a practice to tinker with the schedule. Or maybe the server comes first and they just do everything else to suit. In other words, in all of these types of configuration issues I would expect eBox to attempt to reflect and simplify real world Ubuntu admin behavior and not to attempt anticipating a lot of what ifs, and in this case (well, in most every case), I don't know what the real world behavior might be.
The examples I previously provided of having congested 'quiet time' periods were in fact drawn from my own real world experience of supporting server farms of many Windows servers.  The 'quiet time' was so full that a newly introduced box which demanded a fixed time slot would not have been accommodated.  A different solution would have been found which was able to be integrated into the existing arrangements.

I am sure that given sufficient knowledge of the workings of eBox, or a paid for support contract, the scheduled tasks currently used by eBox are capable of amendment.  This is simply not as easily conducted as it could be - via the web-GUI.
« Last Edit: May 09, 2009, 02:31:52 pm by SamK »

poundjd

  • Zen Warrior
  • ***
  • Posts: 243
  • Karma: +0/-0
  • To your own morals be true!
    • View Profile
Re: Request Clarification of Update Default Action
« Reply #17 on: May 10, 2009, 02:22:42 am »
Sam & Sam, Good points all around, but I have to point out that this is another of those ASS-U-MEtions that I was talking about.  Some developer (bless his/her soul) just assumed that at 12:00 all sane and rational people were not using the boxes.  - While I may agree with that in the large I know that in the small this is simply not true.  I am often working at 12:00 even though I get up at 3:10am on days that I go into the office. ( I'll agree that this is not sane behavior on my part, but it is my behavior on some days). 

But the bottom line is that Exposing this assumption in the GUI and allowing it to be adjusted is just good practice.

Sixstone, Javi & Nicholas,  what do you guys think?

-jeff
Jeffrey D. Pound, Sr.
CISSP
Still learning, hope to never stop!

sixstone

  • Zentyal Staff
  • Zen Hero
  • *****
  • Posts: 1417
  • Karma: +26/-0
    • View Profile
    • Sixstone's blog
Re: Request Clarification of Update Default Action
« Reply #18 on: May 13, 2009, 10:02:12 am »
Quite interesting discussion up here. Let me add my two cents.

Firstly, I've already added your suggestions to the wiki page [1]. They all are reasonable.

Finally, automatic updates are a risky operation since it may break up your box. That happens with the latest dansguardian upgrade... eBox development team is fast to fix bugs but not that faster. We may note that in the automatic updates page.

Best,

[1] http://trac.ebox-platform.com/wiki/Feature/Wishlist/Modules/Software
My secret is my silence...

Sam Graf

  • Guest
Re: Request Clarification of Update Default Action
« Reply #19 on: May 13, 2009, 02:06:20 pm »
Finally, automatic updates are a risky operation since it may break up your box.... eBox development team is fast to fix bugs but not that faster.
Absolutely. By the time somebody discovers the problem and developers are able to release a fix, several hours could have gone by even under good conditions. It's just the nature of things.

For those who opt to take the risk, it would be nice to have some information displayed on the dashboard. A couple of scenarios off the top of my head are failed updates (e.g., due to required user intervention; not sure if or where this might be posted now) and just the fact that an update did (or did not) occur in the last 24 hours. Some frosting on the cake would be a list of what was updated.

I'm considering permanently setting up an eBox sandbox network (potentially good way to use older hardware ;D ) with automatic updates enabled. If the dashboard gave me some brief but critical update status information, that would make things fun. I'd know at a glance if I need to play in the sandbox.

Just a thought ...

SamK

  • Zen Samurai
  • ****
  • Posts: 283
  • Karma: +3/-0
    • View Profile
Re: Request Clarification of Update Default Action
« Reply #20 on: May 13, 2009, 03:21:48 pm »
...By the time somebody discovers the problem and developers are able to release a fix, several hours could have gone by even under good conditions. It's just the nature of things.
...
For those who opt to take the risk (ed of automatic updates), it would be nice to have some information displayed on the dashboard.
...that an update did (or did not) occur in the last 24 hours. Some frosting on the cake would be a list of what was updated.

How about the following as a possible solution.  It is an underdeveloped idea and I'm not even sure it is practical.  Despite this it is offered for discussion.

Is it possible to create a roll-back/fall-back position before updates are applied?

Currently updates are downloaded to /var/cache/apt/archives (hereafter Archive1).  If eBox had directories Archive1, and Archive2 and Archive3 it would be able to operate in a similar manner to the grandfather, father, son model of rotating backups.

At the end of day1 ebox-software:
  • deletes the contents of Archive3
  • moves the contents of Archive2 to Archive3
  • moves the contents of Archive1 to Archive2
  • downloads the pending updates to Archive1

If all install and work OK the process is repeated at the end of day2 (this could be a week or month or whatever update cycle period is preferred).

If the updates fail or break eBox
  • the most recent updates are uninstalled (under the control of eBox)
  • the updates from Archive2 are reinstalled (under the control of eBox)
This would allow the return to a known good condition. 

I presume it would require the eBox developers to construct the process.  If this is achievable it would cater for updates to be conducted either automatically or manually and provide a time buffer to the eBox development team to deal with the cause of any failures.

It might also be worth considering automatically notifying the system administrator (by email?) of a fault condition.

poundjd

  • Zen Warrior
  • ***
  • Posts: 243
  • Karma: +0/-0
  • To your own morals be true!
    • View Profile
Re: Request Clarification of Update Default Action
« Reply #21 on: May 13, 2009, 10:49:39 pm »
It might also be worth considering automatically notifying the system administrator (by email?) of a fault condition.
I would second this idea, and add that an e-mail update to the system administrator for each operation, would be a good thing....  I still shudder at the idea of automatic updates for a server.....
-jeff
Jeffrey D. Pound, Sr.
CISSP
Still learning, hope to never stop!

SamK

  • Zen Samurai
  • ****
  • Posts: 283
  • Karma: +3/-0
    • View Profile
Re: Request Clarification of Update Default Action
« Reply #22 on: May 13, 2009, 11:06:00 pm »
I would second this idea, and add that an e-mail update to the system administrator for each operation, would be a good thing....  I still shudder at the idea of automatic updates for a server.....
I wasn't suggesting that automatic updates only be used.  This is idea (if it works) would be usable irrespective of whether a user chose manual or automatic updates.

I agree that the more cautious user would probably opt for manual control of updates. My feeling is that many users will select automatic updates by inertia.  If this proves to be the case at least the eBox devs would have a time buffer to address the cause, and the user would have a mechanism by which the problem could be sidelined until its resolved.
« Last Edit: May 13, 2009, 11:40:28 pm by SamK »

poundjd

  • Zen Warrior
  • ***
  • Posts: 243
  • Karma: +0/-0
  • To your own morals be true!
    • View Profile
Re: Request Clarification of Update Default Action
« Reply #23 on: May 13, 2009, 11:12:34 pm »
Sam,
     I believe that we are in Violent Agreement....
 :)

I did not think your were saying that.
-jeff
Jeffrey D. Pound, Sr.
CISSP
Still learning, hope to never stop!

SamK

  • Zen Samurai
  • ****
  • Posts: 283
  • Karma: +3/-0
    • View Profile
Re: Request Clarification of Update Default Action
« Reply #24 on: May 13, 2009, 11:18:32 pm »
     I believe that we are in Violent Agreement....
Good to hear this, Jeff.

My knowledge of Ubuntu, apt and eBox is not detailed enough to progress the idea much beyond the concept.  I suppose it is up to the eBox devs to assess it.

poundjd

  • Zen Warrior
  • ***
  • Posts: 243
  • Karma: +0/-0
  • To your own morals be true!
    • View Profile
Re: Request Clarification of Update Default Action
« Reply #25 on: May 13, 2009, 11:29:01 pm »
Sam,
    You and Me both!
-jeff
Jeffrey D. Pound, Sr.
CISSP
Still learning, hope to never stop!

Sam Graf

  • Guest
Re: Request Clarification of Update Default Action
« Reply #26 on: May 14, 2009, 03:05:48 am »
... the more cautious user would probably opt for manual control of updates.
The purpose of an eBox sandbox, of course, would be to test all updates, however managed, before committing production machines to them. Setting up to do system updates automatically in such an environment is simply a convenience.

A Windows-esque restore point feature would be a marvelous thing so long as the machine isn't beyond responsiveness. My guess is that at least some significant percentage of eBox users will have no idea how to recover a tanked Ubuntu server. Or maybe I'm the only one, but in my own little world, that counts. Part of my hesitation with the existing events system (as well as any extension of that idea) is that one cannot absolutely rely on the machine being able to communicate at all, much less informatively.

So, I'm still thinking about how best to approach eBox implementation in my own little world, as an Ubuntu server n00b. With more traditional SMB networks it's all pretty straightforward: If the router takes a dump, you drop your backup into place. If your commercial proxy service wanders off the deep end, you make threatening phone calls. Etc. eBox empowers SMB network admins to do things that they might otherwise not have attempted for whatever reason. Of course, the more plumbing something has, the more chance for leaks. So to me the question is what to do if things go south, for surely they will, sooner or later, whether I was at the helm when they went south or not. At the moment the idea of having things go south in a sandbox first strikes me as one possible way to keep everybody happy.

In effect that's how I'm already doing things -- testing updates on a non-critical network before committing to them on a more critical network. The permanent sandbox idea is just an extension of that approach.

$0.02 spent. Carry on.

SamK

  • Zen Samurai
  • ****
  • Posts: 283
  • Karma: +3/-0
    • View Profile
Re: Request Clarification of Update Default Action
« Reply #27 on: May 14, 2009, 11:09:48 am »
The idea of a fall-back position is not intended to be seen as a 'universal panacea'.  In the imperfect world of computing, by definition such a goal is unobtainable.  Creating a defensible position consisting of multiple layers of protection is probably the best that can be achieved

The purpose of an eBox sandbox, of course, would be to test all updates, however managed, before committing production machines to them.
The use of a testing area such as a sandbox is an excellent one, and well worth including in a multi-layered approach.  I have used such a mechanism in a commercial environment.  The following observations/questions are in no way to be seen as deriding its use.

  • Is the re-use of old hardware able to provide the same results as a production box built from disimilar components?  Is a true hardware replica of the production box required?
  • The forthcoming introduction of eBox machine profiles may lead to a situation where multiple eBoxes are used in a LAN.  Each might conduct a separate role and thereby have a different profile and set of modules.  In such circumstances is a replica of each machine required?
  • The use of a sandbox will quickly highlight the obvious problems such as partial or incomplete upgrades or immediate breakage of eBox facilities.  Would it expose the type of issues that might surface when a user has access to the production system?  If not how does is the system recovered from the issue when it arises?
  • In terms of the effort required to conduct testing, is it practical to test on a daily cycle?


A Windows-esque restore point feature would be a marvelous thing so long as the machine isn't beyond responsiveness.
...one cannot absolutely rely on the machine being able to communicate at all, much less informatively.
A variation of this technique has been successfully used as part of a mechanism supporting Ubuntu server and desktops.  It is entirely OSS and Linux based.  It is not suitable for all installations as it requires the machine to be taken out of service while the updates are applied.

  • Updates are conducted on a cycle appropriate to the site (weekly, monthly or whatever)
  • Before the update process begins a snapshot (image) is taken of the system (OS) disk using a product named Clonezilla http://clonezilla.org
  • The updates are applied and tested
  • The box is returned to production
If unforeseen problems emerge the pre-update condition can be restored within a matter of minutes by reapplying the image.


The balance of ease-of-use against effort, and that of risk against reward, differs from case-to-case and user-to-user.  The present controls offered by eBox by which updates can be managed are rudimentary.  If my suggestion is workable it may offer another layer in the process that leads to machine availability, and help put the wheels back on the wagon when they do fall off.
« Last Edit: May 14, 2009, 11:15:13 am by SamK »

Sam Graf

  • Guest
Re: Request Clarification of Update Default Action
« Reply #28 on: May 14, 2009, 03:04:38 pm »
I'm very interested in following suggestions for improvement, so to clarify my "contribution" on this, I'm just thinking out loud as an Ubuntu server n00b about real world use of eBox 1.0 in production environments. Not large scale stuff like server farms, etc. but SOHO and SMB environments where resources (money and brains) are limited -- the very things which make eBox, even at 1.0, attractive enough to put to the test (along with ourselves). Else I'd just run Ubuntu server like the purists maintain I should: sans eBox. I know we're not altogether on different pages here from earlier comments.

Unless I'm mistaken, eBox will draw more n00bs like me. We'll be a little edgy and out of our comfort zone (there's no comparison between being responsible for, e.g., a Linksys BEFVP41, and an eBox doing all and more of what the blue box did). We'll need to know how to assure management that we have it "all under control." When we suggest taking eGroupWare for a drive as a replacement to a cobbled and unreliable implementation of Outlook, we need to look and sound more confident than we feel. To get there, we have two choices: We can wait until eBox is more robust on the update and recovery fronts, or we can think out loud among ourselves about functional implementation strategies for today, here and now.

That's all I'm doing, really. I've already gotten eBox in the production door by keeping a low profile and by touting the potential. Now it's time either to make good with what we've got or to admit being overly ambitious and move on. A major screwup now will jeopardize the eBox experiment in my little world for at least a couple of revisions into the future. The people using "my" network aren't interested in the back end in itself. They just want to work, and want it to work. Time and money are at stake.

Anybody out of the SOHO and SMB markets that is interested in eBox is interested in either doing things already being done measurably and reliably better or in finding solutions to existing problems. In my case, it's both. And in my case, I have to add Ubuntu server n00bishness to the scenario (clearly there are several here who know what they're doing outside eBox; I'm not among them). I'm hoping just to be among the first of many Ubuntu server n00bs to end up here, since I find eBox an exciting and useful tool. Thinking out loud about the challenges people like me might face in real world implementation today is intended to be my little contribution to the greater discussion about the long term and the possibilities, and to the success of eBox.

The End. ;D

SamK

  • Zen Samurai
  • ****
  • Posts: 283
  • Karma: +3/-0
    • View Profile
Re: Request Clarification of Update Default Action
« Reply #29 on: May 14, 2009, 04:14:54 pm »
Off Topic
@Sam Graf

Sam, my work with large scale deployments was some while ago.  My career took the direction of people management rather than systems management.  At best my skills can be described as 'rusty'.  I view myself as being an eBox n00b and am enjoying the learning process as I am also outside my comfort zone.  I like your phrase of resources, money and brains being limited; this exactly describes my current position.

I find our discussions (such as this thread) enjoyable and worthwhile.  They have already proved to be of interest to the eBox development team as illustrated by the adoption of suggestions into the eBox wish list.

If you are willing to continue 'thinking out loud' I will join you whenever I have anything to add.  Our previous experiences will reflect in what we say today and, when combined with present day experience, may have a beneficial influence on our knowledge and (to a lesser degree) the development of eBox.
« Last Edit: May 14, 2009, 04:18:07 pm by SamK »