Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: SamK on May 06, 2009, 10:43:14 am
-
I am confused about the process by which eBox is updated and hoping to obtain some advice.
Software Management-->System Updates.
This reports that the system is up to date. How can this be tested as the eBox is a fresh install created May 06 2009 from a CD-ROM burned approximately two weeks ago. When using an alternative Ubuntu PC apt-get update and upgrade indicates additional packages are available to install.
Installing eBox v 1 from CD-ROM entries are automatically placed in /etc/apt/sources.list referring to the CD-ROM and Ubuntu security repositories. No other repositories were listed. Is this correct?
How are updates obtained? Which repositories are used?
What have I missed?
-
To add to my earlier post:
Automatic updates are enabled and the software module is enabled but I do not get system, security or eBox updates. Is there a way of testing this is working correctly?
-
Sam,
Edit the config file and comment out the CDROM lines.
-jeff
-
Edit the config file and comment out the CDROM lines.
Already done. I'm stumped. Did you install from CD-ROM? If so can you post the content of /etc/apt/sources.list? I'm not sure what should appear by default. My installation (done 3 times) only listed Ubuntu security repositories.
-
Already done. I'm stumped. Did you install from CD-ROM? If so can you post the content of /etc/apt/sources.list? I'm not sure what should appear by default. My installation (done 3 times) only listed Ubuntu security repositories.
This is a known bug and in 1.2 eBox installer it will include standard Ubuntu repositories.
Regarding to software updates, there is a cron job called ebox-software which every midnight tries to download latest updates and install them if they are automatic switch is on. SamK you may want to run it manually using this command:
$ sudo ebox-software
Best,
-
This is a known bug and in 1.2 eBox installer it will include standard Ubuntu repositories.
Thanks for the information sixstone.
Would you be kind enough to confirm that the repositories listed my post
http://forum.ebox-platform.com/index.php?topic=1260.0 In the section "STAGE 03 - AVAILABILITY", in the code box "Ensure the following entries are listed:" are suitable to be permanently listed in /etc/apt/sources.list. Do you recommend any other repositories to be permanently listed?
Regarding to software updates, there is a cron job called ebox-software which every midnight tries to download latest updates and install them if they are automatic switch is on.
Understood, I will look into this.
SamK you may want to run it manually using this command:
$ sudo ebox-software
Is this the recommended way to apply updates when the automatic switch is off?
-
Sam,
I installed from 1.0
Last login: Fri May 1 23:11:38 2009 from 192.168.1.143
poundjd@ebox:~$ cat /etc/apt/sources.list
#
# 2009 04 10 JDP -commented cdrom entries from list
#
# deb cdrom:[Ubuntu-Server 8.04.2 _Hardy Heron_ - Release i386 (20090121.1)]/ hardy extras main restricted
# deb cdrom:[Ubuntu-Server 8.04.2 _Hardy Heron_ - Release i386 (20090121.1)]/pool/extras/ /
#deb cdrom:[Ubuntu-Server 8.04.2 _Hardy Heron_ - Release i386 (20090121.1)]/ hardy extras main restricted
#deb cdrom:[Ubuntu-Server 8.04.2 _Hardy Heron_ - Release i386 (20090121.1)]/pool/extras/ /
deb http://security.ubuntu.com/ubuntu hardy-security main restricted
deb-src http://security.ubuntu.com/ubuntu hardy-security main restricted
deb http://security.ubuntu.com/ubuntu hardy-security universe
deb-src http://security.ubuntu.com/ubuntu hardy-security universe
deb http://security.ubuntu.com/ubuntu hardy-security multiverse
deb-src http://security.ubuntu.com/ubuntu hardy-security multiverse
-jeff
-
Sam,
I installed from 1.0
Jeff, thanks for this. It is the same as mine. sixstone has indicated that a bug in this version prevents the standard Ubuntu repositories from being listed. I have asked him to confirm those used in my guide to creating a lightweight GUI are appropriate. Once I have this information I will be able to continue testing and will report progress.
-
The confusion mentioned in the opening post of this thread is now clearing.
A bug in the v 1.0 CD-ROM has the effect of creating an incomplete set of entries in /etc/apt/sources.list. Only references to the CD-ROM and Security repositories are created by default. This will be addressed in version 1.2.
A cron job (ebox-software) runs daily at midnight which attempts to locate and download available updates. When automatic updates are disabled this seems to be functionally equivalent to
apt-get update
apt-get upgrade --download-only
The updates are then presented in the eBox Software section for review and installation.
The eBox machine I am currently using is a test rig. Consequently, it is normally powered down at midnight and never obtained any updates. The result was that eBox software pages reported that the installation was up to date, even though running apt on the same machine indicated package updates were available.
The eBox web-GUI is a little confusing in the Software section; I offer the following suggestions for consideration:
- Add a button Check for Updates Now. This will negate the need to run the ebox-software command in a terminal as is required currently.
- Enable the time at which the cron job is run to be changed using the eBox web-GUI.
-
Guys, this points out another request for improvement:
1) The "Run Time" that this update runs should be configurable from the dashboard and a "Run Now" button added as Sam says below.
2) The "Run Time" for all cron jobs should be configurable, and perhaps a default time settable, as well as "Run Now" buttons, where that makes sense.
3) A comprehensive list of these types of Assumptions should be developed and made available for configuration. This is really tough to do, because of the general acceptance in the community in those assumptions is often so strong that they become unconscious and there for very difficult to spot.
I know that at my house all my automatic updates (that I can configure) are set to run between 3 and 5 am (Local TIme), as we are almost all ways in bed before then, but A friend of mine works third shift and sets all of his updates for 9 am because he is in bed and the kids and wife are out of the house.
...
A cron job (ebox-software) runs daily at midnight which attempts to locate and download available updates.
...
The eBox web-GUI is a little confusing in the Software section; I offer the following suggestions for consideration:
- Add a button Check for Updates Now. This will negate the need to run the ebox-software command in a terminal as is required currently.
- Enable the time at which the cron job is run to be changed using the eBox web-GUI.
-jeff
-
I find this discussion interesting because I'm not sure what I think about it all. As a [K]Ubuntu desktop user I admit to be completely comfortable with the fixed, nightly update cycle. It's a given -- one of Jeff's assumptions. On the other hand, since Ubuntu works this way out of the box, it's most likely a Windows-think assumption that makes anyone question it.
If absolutely for no other reason, it makes sense to me for open source projects to try to manage bandwidth by staggering updates in a global fashion. That said, unlike eBox, Ubuntu desktop can fetch the package list from the GUI. Since it's not uncommon for a desktop to be shut down at night or, perhaps just as likely, dual booted into another OS, it perhaps makes more sense to have a GUI-accessible update feature than for a server product.
For what it's worth, my own greatest concern is eBox's automatic system update feature. There's no indication, as far as I'm aware, of just what might have been updated, and when. The DansGuardian update from the Ubuntu repos brought down two of my eBoxes, for example. Since I wasn't using the automatic update system, I don't know if eBox would have let me know on the home page that an update error had occurred or not. I might have woke up to two broken networks and had little to no knowledge of what had happened. There is the event system, but I just don't know ... At least with manual updates, I was on hand to witness the issue and so on hand to do whatever I needed (including taking the eBox off line, if necessary) to address any network failures. I'm not even on site every day, and I can't afford the risk of an automatic update breaking things.
For what it's worth ...
-
Sam, Good points! Maybe one approach would be to allow these things to be set to "Manual" as well, with documentation that outlines why it is needed and a suggested schedule.
-jeff
-
...I admit to be completely comfortable with the fixed, nightly update cycle. It's a given -- one of Jeff's assumptions.
I am also in favour of regular updates. My suggestions are aimed at the 'fixed' elements. The updates can only be obtained manually via the command line and the time that they are obtained also cannot be adjusted at the eBox web-GUI.
Two examples by way of illustration:
- When building any computer using either Windows or Linux, applying patches and updates is normally a standard step in the procedure. Under Windows OSs and Ubuntu Desktop this can be done on demand without resorting to the command line.
- IT related tasks are often conducted 'out of office hours'. Backups are normally scheduled to be conducted when there is little demand on the data sources or network. The important point here being scheduled. To fit well with this eBox conducts its own maintenance tasks be run during what may be regarded as 'quiet time' for many operations. This will vary from user to user. To be most user friendly the ability to adjust the eBox scheduled tasks (cron) via the web-GUI would seem worthwhile.
In my view, both the above correspond well with the eBox philosophy of making the life of the system administrator easier and simpler.
For what it's worth, my own greatest concern is eBox's automatic system update feature. There's no indication, as far as I'm aware, of just what might have been updated, and when. The DansGuardian update from the Ubuntu repos brought down two of my eBoxes, for example.
...I can't afford the risk of an automatic update breaking things.
I fully agree with this. eBox would be an improved product if it provided an option to indicate the what and when linked to the success or failure of the operation.
Automatic updates may ultimately prove to be the choice selected by most users. The impact of failures will be reduced for those eBox clients on a paid for contract which includes guaranteed response/fix times. Other users may accept the impact where fixes provided by eBox staff on the forums is acceptable. For the remainder the degree of manual control that can be exercised is important.
Maybe one approach would be to allow these things to be set to "Manual" as well, with documentation that outlines why it is needed and a suggested schedule.
I agree with this viewpoint. Discussions such as this may help influence the way in which eBox develops and matures.
-
I am also in favour of regular updates. My suggestions are aimed at the 'fixed' elements. The updates can only be obtained manually via the command line and the time that they are obtained also cannot be adjusted at the eBox web-GUI.
I see what you're saying about the time. My only point is that this isn't even a stock feature of Ubuntu desktop and so not part of the Ubuntu culture, as such.
The part about "updates can only be obtained manually via the command line" isn't clear to me. I commented out the CD-ROM references and added a single line to sources.list (found in these forums) and with that I pretty much let eBox tell me what's available for updates. I use the command line only in rare special cases. So I must be missing something here.
To be most user friendly the ability to adjust the eBox scheduled tasks (cron) via the web-GUI would seem worthwhile.
I do see the point. Again, I'm undecided about this just because it's not part of the stock Ubuntu experience, not on the desktop and, as far as I can see, not something offered during server setup. I don't mean to say by that that there is no benefit to the suggestion, only that it's not necessarily a weakness of eBox if it does not support easy package list fetch scheduling, since Ubuntu itself doesn't either. Maybe there is simply no felt need in Ubuntu-think for this type of functionality. That is, if it were a normal part of Ubuntu server (or desktop for that matter) to make it easy to schedule the package list fetch for update purposes (a la Windows) and eBox left that functionality out, I think I would look at it differently. That's all.
Not that I necessarily see agreeing with Ubuntu-think as the default correct course of action, of course ... but working in Ubuntu while thinking in Windows just makes the obtuse world of Linux all the more obscure to a simple and aging mind like mine. :)
-
The part about "updates can only be obtained manually via the command line" isn't clear to me.
...
I use the command line only in rare special cases. So I must be missing something here.
Perhaps another example might help clarify my point.
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.
sixstone has advised that the way to achieve the forced download is to run
sudo ebox-software
This command simply runs the cron job (which is scheduled for midnight each day) that downloads and optionally installs the updates. The point being that the functionality to obtain updates on demand already exists within eBox, it is simply not accessible via the web-GUI; hence my suggestion to include a button, Check for Updates Now.
The suggestion is not intended to replace the scheduled update function but to enhance eBox's user friendliness at a minimal programming cost.
To be most user friendly the ability to adjust the eBox scheduled tasks (cron) via the web-GUI would seem worthwhile.
I do see the point. Again, I'm undecided about this just because it's not part of the stock Ubuntu experience...
In an earlier post I made reference to IT tasks being conducted 'out of office hours' and during 'quiet time'. The number of maintenance/housekeeping tasks to run during these periods can often lead to the position where the time available is entirely (or almost entirely) used. The usual answer is to carefully stage/schedule these tasks to obtain the 'best fit'. In these circumstances, achieving a balance of conflicting demands is necessary.
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.
My initial suggestion related only to obtaining updates, however if my understanding is correct, Jeff extended the argument to include a wider range of eBox scheduled tasks.
...
3) A comprehensive list of these types of Assumptions should be developed and made available for configuration. This is really tough to do, because of the general acceptance in the community in those assumptions is often so strong that they become unconscious and there for very difficult to spot.
This does seem helpful in balancing competing demands in a wider network scenario.
Off Topic
...to a simple and aging mind like mine.
One that is sharp and self evidently able to contribute well constructed points. Perhaps not that simple or old.
-
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. :-\
-
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.
-
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
-
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
-
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 ...
-
...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.
-
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
-
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.
-
Sam,
I believe that we are in Violent Agreement....
:)
I did not think your were saying that.
-jeff
-
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.
-
Sam,
You and Me both!
-jeff
-
... 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.
-
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.
-
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
-
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.
-
and besides all that good stuff it is fun to learn! :D
-jeff
-
To summarise, recent posts could be categorised under the general heading of preventative measures:
- The relative merits and dangers of automatic v manual updates
- The use of a testing area (sandbox)
Both offer the system administrator practical means of (today) reducing the risk of a system failure as a result of updating it. Neither rely on extending the present functionality of eBox; they are examples of good practice.
Eventually, a system failure will occur. It then becomes a question of recovery measures, i.e. how the system is to be restored to operational condition. Two possible approaches to creating a fall-back position have been outlined:
- The use of imaging technology
- Rolling back the updates
Both offer the system administrator a means of reacting to unforeseen conditions.
Imaging can be used today; it does not require additional development of eBox. It is beyond the scope of eBox and might (quite properly) never be integrated with it. The example given in an earlier post illustrates its use on a machine removed from service during the upgrade. This might limit the appeal of imaging to some system administrators.
Rolling back the updates (as described earlier in the thread - see post #20) is the underdeveloped idea that was initially offered for discussion. If this is a workable idea, it will be operated manually from within the web-GUI (or automatically) and therefore will require input from the eBox team. It is not to be viewed as a replacement for good practice measures but is intended to to be used in conjunction with them.
In a situation where updating places eBox in an unresponsive condition, the eBox support team will be in exactly the same position as that faced should the condition occur today. Hopefully such a condition will be a rare and unusual event. When the machine remains responsive (following an update problem) the roll-back mechanism would confer the following major benefits:
- The system remains available to the end users
- The eBox developers and system administrator gain a time buffer to resolve the issue
- The eBox support team has a controlled mechanism (that they have designed and understand) which enables them to provide advice and rectify the matter more effectively.
Is this feasible?
-
As this discussion seems to have reached a natural conclusion, I have raised the idea of a fall-back position in the Feature Requests Section here:
http://forum.ebox-platform.com/index.php?topic=1364.0