On Monday 19 December 2005 20:35, Dan Brown wrote:
>Whoops, this was meant to go to the entire list.
>
>Gene Heskett wrote:
>> On Monday 19 December 2005 17:53, Dan Brown wrote:
>>>I have recently just upgraded amanda an amanda installation from
>>>2.4.4p1 and upgraded the backup host from RedHat 7
Whoops, this was meant to go to the entire list.
Gene Heskett wrote:
On Monday 19 December 2005 17:53, Dan Brown wrote:
I have recently just upgraded amanda an amanda installation from
2.4.4p1 and upgraded the backup host from RedHat 7.3 to Fedora FC4.
I've also conglomerated the backed up h
sk]
> oldgimp /var/lib/mysql lev 0 FAILED [dumps too big, 12627455
> KB, but cannot incremental dump
> new disk]
> oldgimp /everythingelse lev 0 FAILED 20051219 [dumper3 died]
> oldgimp /homelev 0 FAILED 20051219 [dumper4
On Monday 19 December 2005 17:45, Paul Seniuk wrote:
>Thanks for the reply
>
>After comparing this server to 9 others in the dump, amanda client
> seems to be installed fine.
>
>I did discover that this server was comprimsed and was running a SPAM
>script from /usr/lib/asterisk/.amandad .g
On Mon, Dec 19, 2005 at 06:47:15PM -0500, Paul Seniuk enlightened us:
> Matt,
>
> Well you were right and that worked. Annoying story to it ...collegue
> decided to upgrade the box to FC4 and not tell me.
> The upgrade turned SELinux on by default.
>
> Merry Xmas Matt and thanks :)
>
>
Sounds
Matt,
Well you were right and that worked. Annoying story to it ...collegue
decided to upgrade the box to FC4 and not tell me.
The upgrade turned SELinux on by default.
Merry Xmas Matt and thanks :)
Paul Seniuk
Hosting Division,
Thinktel Communications
-Original Message-
From: [EMAIL
On Mon, Dec 19, 2005 at 05:45:45PM -0500, Paul Seniuk enlightened us:
> Perms on /etc/dumpdates is:
>
> -rw-rw-r-- 1 root disk 172 Dec 16 02:37 dumpdates
>
> Would anything be logged about failing to create /etc/dumpdates (get
> that long pole out, I used the RPM version for CentOS) ?
>
> For '
not incremental dump
new disk]
oldgimp /var/lib/mysql lev 0 FAILED [dumps too big, 12627455 KB, but
cannot incremental dump
new disk]
oldgimp /everythingelse lev 0 FAILED 20051219 [dumper3 died]
oldgimp /home lev 0 FAILED 20051219 [dumper4 died]
oldgimp /zu/incoming
Thanks for the reply
After comparing this server to 9 others in the dump, amanda client seems
to be installed fine.
I did discover that this server was comprimsed and was running a SPAM
script from /usr/lib/asterisk/.amandad .god forbid I ever run into
these script kiddies on the street.
On Monday 19 December 2005 13:20, Paul Seniuk wrote:
>For some reason, one of my clients returns this:
>
>ERROR [can not read/write /etc/dumpdates: Permission denied]
>
>The file permissions are proper and user amanda can access the file.
>
>Any ideas of what else could be thorwing this error on th
On Mon, Dec 19, 2005 at 01:20:56PM -0500, Paul Seniuk wrote:
>
> For some reason, one of my clients returns this:
>
> ERROR [can not read/write /etc/dumpdates: Permission denied]
>
> The file permissions are proper and user amanda can access the file.
>
> Any ideas of what else could be thorwin
For some reason, one of my clients returns this:
ERROR [can not read/write /etc/dumpdates: Permission denied]
The file permissions are proper and user amanda can access the file.
Any ideas of what else could be thorwing this error on the client?
Missing libraries perhaps? (client used to work)
I think the essence is that while both are encryption, one is applied
to transport and one to storage. Thus, were we starting fresh I'd
recommend
transport_encryption
storage_encryption
Since we aren't, I think we should go with
encryption# transport, but holding disk and tape
Greg Troxel wrote:
In 2.4, there is a "kencrypt" option that uses Kerberos to negotiate a
session key and encrypts the dumps from the client to the server.
They are then in the clear on the holding disk and tape. This
protects against eavesdroppers on the wire, but not someone who can
get the ta
In 2.4, there is a "kencrypt" option that uses Kerberos to negotiate a
session key and encrypts the dumps from the client to the server.
They are then in the clear on the holding disk and tape. This
protects against eavesdroppers on the wire, but not someone who can
get the tapes. At the same tim
Hello!
I saw that when it failed and ripped the tape in two on one drive
back in jurrasic times.
So who's throwing away the information ?
The tape drive not sensing these holes ?
The low level driver not recognising or not asking for the info ?
The general linux/unix tape system not recogni
16 matches
Mail list logo
