Hi Graeme,

> it's interesting to read of your perspective on e-smith and to hear about
> it's use in Spain.  I find it really hard to understand how a UPS can be
> such an impediment however.  Are they really that expensive in Spain?  I
> can buy an adequate, serial monitored UPS for 16289.00 Spanish Pesetas -
> does this seem like a lot?

  As I said this is not a price problem but a "cultural" problem. He is a
Windows 98 "expert" and you know, windows doesn't need a UPS unit to protect
its filesystem :) Even worse, our SUSE solution has just complicated the
question as he expects the same from e-smith (ohhh, wasn't linux supposed to
support this?). In this case a UPS would be the perfect solution but that
was not the reason of my post. What I'm trying to say is that maybe e-smith
is "too" easy to install letting "an expert" very few flexibility (at the
same time I believe is the best distro for a business server).

> For a device that protects your server from power surges, power failure
> and your filesystem it seems pretty cheap and is easy to bundle with the
> cost of the server.  I've been selling UPSs with servers for years,
> sometimes without monitoring as actually protecting from powersurges is at
> least as important as a properly dismounted filesystem.  It sounds to me
> like you need to educate your clients better on this issue, not avoid it.

  You are perfectly right. This is a 1 client (better to call him friend)
problem, but what happens when you are talking about 500? I agree with you
an UPS is a must for a server, but at the same time I think some kind of
journalling filesystem makes a good situation even better (or what I called
a more robust system).

> On the issue of partitioning, I hear you. But you can modify the kickstart
> file on the install disk if you wish to partition the system differently.

  Yes, I know this. I just try to point the lack of flexibility.

> With respect to backup however I think you are wrong to think nightly
> tarballs to a different partition = backup.  A good backup should:
> - use removeable media separate from the filesystem and computer being
> backed up.  Anything else is just data redundancy, not backup.
> - include sequential copies of the data, allowing retrieval to a number
> of points in time.
> - include a regularly exchanged copy taken off-site, so in the event the
> building burns down you'll still have a copy of the data.

  OK, maybe I should present you the "old" backup procedure. When they lost
this client data I asked the boss "Do you have a backup?" He said "Nop" I
followed "Well, you just losted a client". Once we implemented this "backup"
procedure I told him to burn a CDRW every week and a CD everymonth (for
archive). This was 12 months ago. The other day we went to the office and
asked to see the CD backups. He had made just 2 of them and there was no
CDRW around. What I'm trying to say is: I cant be sure he will make a manual
backup (too lazy or just weak memory :)) I cant ask a person that needs help
to install a cd burner unit in windows to install AND use a tape unit. What
do I have? Something thats automatic and at least better than nothing, a
second hd seemed a good solution, specially if you combine it with the cd
burner (the biggest backup has been of 400 MB) I know this might not be a
"academic" backup but makes the job.

> It's good to hear from an enthusiastic user of SuSe.   I ran 6.0 on my
> desktop for a while but have reverted to Redhat in order to have a system
> for building rpms easily.

  I have used SUSE 6.0, 6.1, 6.3 and 7.0, Redhat 6.1, Debian and Mandrake.
I'm also thinking about swithing to Red Hat to make my development for
e-smith easier.

> Best wishes,

  Regards.


--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org

Reply via email to